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The A-party generates ' LOGOUT * according to the criteria 
and with the structure stated in Appendix A. 



Dialogue 14.1: 
" Subscription initiates log-out. 



A NETWORK 
' LOGOUT ' 1 



Dialogue 14.2; 

Network initiates logout. 

The subscription has sent a LOGINREQ from a terminal but 
is still registered as logged-in to another terminal. The 
network will then send LOGOOTORD to the old terminal 
according to the criteria and with' the format stated in 
Appendix A. 

The personal subscription should immediately be deleted 
from the B-party's flexlist. 



NETWORK B 
' LOGOOTORD ' 1 



If the network has sent a LOGOOTORD and the old terminal 
did not receive it, the LOGOOTORD is repeated when the 
subscriber sends a message next time. 
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15 ACTIVATION 

The A-party generates ' ACTIVE ' according to the criteria 
and with the format stated in Appendix A. 



Dialogue 15.1: 

Activation is approved and the mailbox is empty. 

A NETWORK 
1 ACTIVE ' 1 



Dialogue 15.2: 

Activation is approved and there are packets in the 
mailbox, both for the terminal and the personal 
subscription. 



MSG 1 and 2 are packets (MPAK) that has been stored in the 
network mailbox while the terminal has been inactive. 
Each packet sent out from the mailbox is delayed a certain 
time in order not to overload the terminal. 
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16 INACTIVATION 



The A party generates 'INACTIVE' according to the criteria 
and with the format stated in Appendix A. 



Dialogue 16.1: 
Inactivation. 



NETWORK 
' INACTIVE '1 
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17 DIE - LIVE 



The network generates 'DIE' and ' LIVE * according to the 
criteria and with the format stated in Appendix A. 

when the terminal receives 'DIE' it is not allowed to send 
any user traffic to the network, until a 'LIVE' has been 
received. Dser traffic is defined. as packets included in 
the packet classes; PSQBCOM, PSOSCOM and CSOBCOM. The 
terminal may send DTESEHV packets. 



Dialogue 17.1; 

The terminal may not send user traffic. 



'DIE' is stored in the network mailbox if the B-party is 
not active. The packet is sent out according to Dialogue 
15.2 when the B party is active again. 



Dialogue 17.2 ; 

The terminal may send packets again. 



'LIVE' is stored in the network mailbox if the B-party is 
not active. The packet is sent out according to dialogue 
15.2 when the B-party is active again. 
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' Dialogue 18.1; 

The network requests the terminal to send a ROAM packet. 

The network generates 'ROAMORD' according to the criteria 
and with the format stated in Appendix A. 



' ROAMORD 1 1 



The B-party generates 'ROAM' 2 according to the criteria 
and with the format stated in Appendix A. 



Dialogue 18.2: 

The A-party generates 'ROAM' spontaneously according to 
the criteria and with the format stated in Appendix A. A 
spontaneously generation of a ROAM packet is initiated 
from the roaming procedure described in the mobile 
terminal data link layer. 
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19 RE-DIRECTION OP EMERGENCY MESSAGES 



This is used when the emergency messages should be sent to 
the alternative emergency receiver. 

The A party generates 'VICESOSRX' according to the 
criteria and with the format stated in Appendix A. 



Dialogue 19.1: 

The re-direction is approved. 



'VICESOSRX' 1 



Dialogue 19.2: 

The ■VICESOSRX' is returned from the network. 



NETWORK 
' VICESOSRX * 1 



'VICESOSRX' 2 



a) Re-direction cannot/may not take place. 

' VICESOSRX ' 2 is returned with traffic state = ILLEGAL 

b) The network is overloaded. 

' VICESOSRX ' 2 is returned with traffic state = CONGEST 

c) A technical fault may have occurred. 

' VICESOSRX ' 2 is returned with traffic state = ERROR 
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20 CANCEL RE-DIRECTION OF EMERGENCY MESSAGES 



Dialogue 20.1: 

The re-direction is cancelled. 



Dialogue 20.2: 

The cancellation of the re-direction cannot/may not be 
accepted. 



•SOSRX' 2 is returned with traffic state = ILLEGAL 
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21 UPDATING GROOPLIST 



Dialogue 21.1; 



The network generates 'GROOPLIST' according to the 
criteria and with the format stated in Appendix A. 



NETWORK 

'GROOPLIST' 1 



•GROOPLIST' is stored in the network mailbox if the B 
party is not active. The packets are sent out according to 
dialogue 15.2 when the B party is active again. 
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22 UPDATING THE LIST OF PERSONAL SUBSCRIPTIONS 



Dialogue 22.1: 

The network generates 'FLEXREQ' according to the criteria 
and with the format stated in Appendix A. 



'FLEXLIST' 2 



'FLEXLIST' is generated according to the criteria and with' 
the format stated in Appendix A. 



Dialogue 22.2: 

The network generates 'FLEXLIST* according to the criteria 
and with the format stated in Appendix A. 

NETWORK B 
' FLEXLIST ' 1 

' FLEXLIST ' is stored in mailbox if the B party is not 
active. The packet is sent out according to dialogue 15.2 
when the B party is active again. 
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23 TECHNICAL INFORMATION 



Dialogue 23.lt 



The network generates * INFOREQ 1 according to the criteria 
and with the format stated in Appendix A. 



24 TIME INFORMATION 



Dialogue 24.1: 



The network generates 'TIME' according to the criteria and 
with the format stated in Appendix A. 
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25 UPDATING AREALIST 




Dialogue 25.1: 





The network generates 'AREALIST' according to the criteria 
and with the format stated in Appendix A. 



NETWORK 

'AREALIST" 1 



'AREALIST' is stored in the network mailbox if the B party 
is not active. The packets are sent out according to 
dialogue 15.2 when the B party is active again. 



26 ELECTRONIC SERIAL NUMBER CHECK 



Dialogue 26.1; 

The network generates ' ESNREQ * according to the criteria 
and with the format stated in Appendix A. 
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MOBITEX 

Network layer for terminals 
Appendix C. Logical description 



ABSTRACT 

This document contains the logical description for the network 
layer for mobile terminals connected to the MOBITEX system. 
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1.1 DATA FLOW DIAGRAM 

The data Elow diagram below shows the interaction between the 
network layer and the other two layers; the data link Layer and the 
application layer. 



| Application Layer { APP ) | 




.3 \ 


' 4 



NETWORK LAYER 





l ' 1 y 


r 2 


| Data Link Layer ( LINK ) 



Signals to/from Data Link Layer. 

-1- MPAK transmitted, MPAK_not_transmitted, MPAK_received, 
roaming, activation 

-2- MPAK_to_transmit, MPAK_to_retransmit, speech_on, speech_off , 
order_to_return MPAK, group_list_information, 
area_list_information 

Signals to/from Application Layer. 

-3- MPAK_received, returned_MPAK_with_code, die, live,- buffer_full 

-4- MPAK_to transmit, hook_6n, hook_off, power_off, 
manual mode on, MPAK to retransmit 
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1 . 2 TERMINOLOGY 
P_ / F_ 

input_signal 

wait_for_input_signal 
save_signal 



ignore_signal 
grouplist 
flexlist 
permanent_list 

g r oupl i s t_r ecei ved_f lag 

active_delay_power_up 
active_delay_lost_contact 
power_of f_ready 



In this logical description, all 
procedures starts with "P_" , and all 
functions with M F_". 

The network layer has an input queue. A 
signal from this input queue is called' 
"input_signal". 

The. network layer is waiting until' un 
input_signal is available. 

Restoring the signal into the queue. 
This is done when you expect a certain 
signal. By repeating input_signal and 
save_signal, you can search in the 
input queue for certain signals. All 
saved signals are available when an 
input signal fallows after an 
- input_signal. without any save_signal 
between. See chapter 'Queue handling'. 

No further handling of this signal, 
except that the signal should be 
'deleted. 

Area where group HAN are stored. This 
list should be stored also during power 
off. 

Area where personal subscription MAN 
are stored. This list should be stored 
also during power off. 

Total area to be continuously stored. 
In this area terminal MAN, serial 
number, group list, flexlist, die_state 
and live_state are stored. The checksum 
is calculated based on this list. 

Indication of a correct permanent list 
and that a MPAK: GROUPLIST is received 
or not. 

Activation delay concerning power-up 
and manual radio mode. See Rl-06. 

Activation delay concerning lost 
contact. See Rl-06. 

Flag to indicate that the network layer 
is ready to be closed. 
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raanual_mode Flag to indicate that the mobile 

station is in manual mode. 

buff er_full_f lag Indication of buffer full. 

emergency_flag Indication of an activated emergency. 

When application layer receive an 
emergency signal, this flag is raised. 
Now the network layer can handle the 
priority of emergency in the terminal. 
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1.2 SIGNALS 

MPAK_to_transmit 

MPAKjreceived 

MPAK_trarismitted 
MPAK_not_transmitted 
HPAK_t o_r et r ansmi t 

roaming 
activation 

speech_on 

speech_off 

order_to_return_MPAK 

group_list_information 
area_list_information 
returned MFAK_with code 



MPAK received from the application 
layer or MPAK to the data link layer to 
be transmitted. 

MPAK received by the data link layer or 
MPAK to be sent to the application 
layer. 

MPAK successfully transmitted by the 
data link layer. 

MPAK not transmitted by the data link 
layer . 

MPAK from the application layer to the 
data link layer to be retransmitted 
(special treatment in the data link • 
layer). 

Order to the network layer to send an 
MPAK: ROAM. 

Start activation timeout (after power- 
on or lost contact with base) given in 

Rl-06. 

Order to the data link layer to set 
mode speech_on. 

Order to the data iink layer to set 
mode speech_off. 

Order to the data link layer to stop 
sending an MPAK, and return the MPAK to 
the network layer. 

Group list information to the data link 
layer . 

Area list information to the data link 
layer . 

Returned MPAK with code information 
from the network layer. The code shows 
why the MPAK was returned. 
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hobk_on 


Hook_o 
layer. 


n signal from the application 




hook_off 


Hook off signal from the application 
'layer". 




die 


A signal informing that the network 
layer has received an MFAK:DIE. All 
user traffic is stopped and returned to 
the application layer. 




live 


A signal informing that the network 
laysr h3S rscsivsd* <in MPAKiLIVE* Ussr 
traffic from the application layer can 
be handled. 




bufferjEull 


Incoming and outgoing traffic from/ to 
the MOBITEX network is stopped. The 
network layer tries to send 
MPAK j INACTIVE. Application layer is 
informed. When the message buffer has 
space for at least 6 messages, 
according to specification Rl-09, the 
buffer_full_flag is reset and incoming 
and outgoing traffic is resumed. 




power_off 


The application layer wants to turn the 
network layer off.' The network layer 
tries to send an MPAK: INACTIVE. 




power_off_timeout 


Internal timeout to indicate that the 
network layer is ready to be turned 
off. 




iuanual_mode_on 


The application layer wants to turn 
over to manual radio mode. The network 
layer tries to send an MPAK: INACTIVE. 




raanual_mode_on_timeout 


Internal timeout to indicate that the 
network layer is ready to turn over to 
manual radio mode. 
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RETURNED HPAK WITH CODE 



CODE 



SENT ■ 
NOT_SENT 
NOT SE ' 



NOT_SENT_D IE 

NOT_SENT_BUFFER_FULL 

INCORRECT 

PERSONAL_HAN_EXI ST 
PERSONAL_HAN_NOT_EXIST 
FLEXLIST FULL 



This HPAK has been correctly sent by the 
data link layer. 

This HPAK has not been correctly sent by 
the data link layer. . 

This HPAK has not been' sent because of 
speech state in the network layer. 

This HPAK has not been sent because of die 
state in the network layer. 

This HPAK has not been sent because of 
buffier_full state in the network layer. 

Received HPAK from the application layer, 
do not have a correct format or is not 
allowed to be sent. 



The maximum number of HAN in the flexlist 
is exceeded. 



AJ32JISM 
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1 • 4 STATES 
idle 

die state 



sending_during_die 

linkjbusy 

sending_conreq 
stop_s ending 

wai t_f or_hook_of f _norraal 
wait_for_hook_off_fast 
wai t_for_hook_pff_g roup 

sending_conrea 

speech_normal 
speech_group 

sending_discon 



Idle state 

' A received MPAK:DIE has ordered the 
mobile to this state. No outgoing user 
traffic is allowed. A received 
MPAK:LIVE orders the mobile to idle 
state. 

Only MPAK of class DTESERV and 
HPAK:DISCON (CSUBCOM) can be sent 
during die_state. " 

The data link layer can only handle one 
packet at a time. In the present state, 
the data link layer is busy. 

The data link layer is busy sending 
speech request. 

The network layer has ordered the data 
link layer to stop sending present 
packet. The network layer is waiting 
until the data link layer is ready. 

A normal speech request is received and 
the network layer is waiting for 
response from the 'application layer. 

A fast speech request is received and 
the network layer is waiting for 
response from the application layer. 

A group speech request is received and 
the network layer is waiting for 
response from the application layer. 

The data link layer is busy sending a 
hook_off signal (MPAK:CONREA) . 

The network layer is in speech state. 

The network layer is in group speech 
state. 

The data link layer is busy sending a 
hook_on signal { MPAK : DISCON) . 
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1.5 STATE DIAGRAM 



STOP 




SENDING 




WAIT FOR 


SENDING 




CONREA 




HOOK OFF XXX 



SENDING 
DISCON 



WAIT_FOR_HOOK_OFF_XXX can be in three different states depending on 
the received speech request, as follows: 



STATE 

WAIT_FOR_HOOK_OFF_NORHAL 

WAIT_FOR_HOOK_OFF_FAST 
WAIT_FOR HOOK OFF GROUP 



WHEN RECEIVING 

CONREQ, ADDCONREQ, SOSCONREQ or 
EXTCONREQ 

CONFAST, ADDCONFAST or SOSCONFAST 
CONORD 
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1.6 QUEUE HANDLING 

input queue: 
2 , 



Input_signal: 

3 | 
2 | 



Save_signal: 



Input_signal 
3 I 



and save_signal: 



1 r 



Input_signal : 
4 I 

3 I " 



Input_signal : 



input_queue_pointer 



input_queue_pointer+l 
signal available for user 



input_queue_pointer+i 
save_input_queuejpointer 



input_queuejaointer+2 
save_input_queue_pointer+l 
sa ve_i npu t_queue_poi n t e r 

input_queue_pointer+3 
signal available for user 
save_input_queue_pointer+l 
save_input_queue_pointer 



input_queue_poi n t e r +1 
signal available for user 
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2 LOGICAL DESCRIPTION 






2.1 Start of program 






This program have two different modes, MOBITEX mode and MANUAL mode. 
In MANUAL mode, the network layer is stopped. 

When MOBITEX mode is activated from MANUAL mode the network layer 
should be restarted. 




NETWORK^LAXER 

P activation handling 
next_state =~idle 
emergency flag = FALSE 
IF permanent list is not correct THEN 
make MPAK BORN 

send MPAK_to_transmit to LINK 
next state =~link busy 
reset grouplist and flexlist 
set NOT grouplist received flag 
ENDIF 




LOOP 

IF manual mode THEN 

MOBITEX network layer inactivated 
activated = FALSE 
• handle manual mode 




wait for input signal 
IF- emergency flag THEN 
P look foF emergency 
ENDIF 

CASE signal 






WHEN MPAK to transmit from APP 

P_MPAK~FROM_APP 




WHEN MPAK to retransmit from APP 
P_MPAK~TOJlETRANSMIT 




WHEN MPAK received from LINK 
P_REC_MPAK_FROM_L INK 




WHEN MPAK transmitted from LINK 
P_MPAK_TRANSMITTED 




WHEN MPAK not transmitted from LINK 
P_MPAK~NOT~TRANSMITTED 




WHEN hook on from APP 
P_HOOK~ON_handling 

WHEN hook off from APP 
P_HOOK~OFF_handling 

WHEN hook_off_timeout 
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P_t imeout_handl ing 

WHEN roaming from LINK 
P_roaming_handling 

WHEN activation from LINK 
P_activation_handling_link 

WHEN activation timeout 

P_activationJ:imeout_handling 

WHEN power_off from APP 
P_powe r_of f _handl i ng 

WHEN manual_mode_on 

P_manual_raode~on_handling 

WHEN power_off timeout 
set power_of"f_ready 

WHEN manualjnode. on_timeout 
set raanual_moa"e 

WHEN buffer_full 

P_buffer~full_handling 



END_NETWORK LAYER 
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2.1.1 P_LOOK_FORJEMERGENC¥ 




P look for esifirgsncy 




emergency_signal = FALSE 




WHILE NOT emergency_signal THEN 




CASE - MFAR ■ type 




WHEN SOS , SOS INFO , SOSACK , SO 
eraergency_signal = TR 


SCONREQ , SOSCONFAST 
OE 


WHEN OTHERWISE 

save_signal 
input signal 

ENDCASE 




ENDWHILE 
END_P_look_for_emergency 





A2S2J1SM 
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2 . 2 P_MPAK_FROM_APP 



P_KPAK_FROH_APP 

IP NOT buffer_full_flag : 
CASE next_state"~ 



I idle 

CASE HP AK. class 
WHEN PSUBCOM,PSOSCOM 
P_checlc format 
IP format = true THEN 

send MPAK_to_transmit to LINK 
next_state = LINKJBUSY 
ELSE 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP ~ 
WHEN CSOBCOM 

P_check_forraat 

IF format = true THEN 

P_check_and_send_CSOBCOM 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP ~ 
WHEN DTESERV 

P_check_format 

XP format = true THEN 

P_check_and_send_DTESERV 
ELSE - ~ ~ 

send returned MPAK_with_code: INCORRECT to APP 



ENDCASE 
I die_state 

IF MPAK. class = DTESERV THEN 
P_check_format 
IP format = true THEN 

P check and send DTESERV 
ELSE" 

send returned MPAK with code : INCORRECT to APP 
ENDIP ~ 
ELSE 

send r eturned_MPAK_with_code : NOT_SENT_DIE 
ENDIP 

I wai t_f or_hook_of f _normal , 
wait_f or_hook_of f _f ast , 
wait_for hook off_group 
IF MPAK. class = CSOBCOM THEN 
P_check_f o rraat 
IF format = true THEN 
CASE MPAK. type 
WHEN CONREA 

P_hook_off_handling 
WHEN DISCON 

P hook_on_handling 
WHEN~OTHERWI SE 
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send returned_MPAK_with_code :NOT_SENT_SPEECH 




WUWUB 

send returned MPAK 
ENDIF 


_with_Code: INCORRECT to APP 




IF MPAK. Class = PSOSCOM THEN 

save signal 
make hook on signal 
P HOOK ON handling 
ELSE ~ 

send returned MPAK with code: NOT SENT SPEECH to APP 
ENDIF 
ENDIF 

WHEN sending conr eg, sending conrea,speech_normal,speech_group 
IF MPAK. class = CSUBCOM THEN 
P check_format 
IF format .= true THEN 
CASE MPAK. type 
WHEN DISCON 

P^ook^n^handling . 
WHEN OTHERWISE 

"send returned MPAK with coderNOT SENT SPEECH 




ENDCASE 
ELSE 

send returned MPAKjwith_code: INCORRECT to APP 
ENDIF 




ELSE 

IF MPAK. class = PSOSCOM THEN . 
CASE next state 

WHEN sending _conreq,sending_conrea 
save signal 

send order to return_MPAK to LINK 

next state = stop sending 
WHEN speech normal, speech_group 

save_signal 

make"~hook on signal 

P HOOK ON~handling 
ENDCASE 




ELSE 

send returned MPAK with coderNOT SENT SPEECH 
ENDIF 




ENDIF 
WHEN OTHERWISE 

save signal 
ENDCASE 






ELSE 

CASE MPAK. class 
WHEN PSOBCOM, PSOSCOM 
P check- format 
IF format = true THEN 

send MPAK to transmit to LINK 
next_state = LINK_BUSY 




send returned_MPAK_with_code: INCORRECT to APP 
ENDIF 
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WHEN OTHERWISE 

send t etur ned_MPAK_wi t*i_code : NOT_SENT_BOFFER_FULL 
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2.2.1 F_CHECK_FORMAT 






F_check_format 






This routine checks and completes the format of this MPAK to be 

correct according to Rl-09 Appendix A. 

A correct MPAK will be returned with format = TRUE. 

An incorrect MPAK will be returned with format = FALSE. 




END_F_checfc_format 






2.2.2 P_CHECK_AND_SEND_DTESERV 






P check and send DTESERV 
CASE MPAK. type" 






WHEN LOGINREQ 

IF MPAK. type dependent in our flexlist THEN 

send returned MPAK with code : PERSONAL_MAN_EXIST to APP 




ELSE 

IF more space in our flexlist 
MPAK. sender = MCU MAN 
send MPAK to transmit to LINK 
next_state =~LINK_BUSY 




send returned MPAK with code : FLEXLIST_FULL 
ENDIF 

endif' 




WHEN VICESOSRX r SOSRX 

IF MPAK. sender in our flexlist THEN 
send MPAK to transmit to LINK 
next state =~LINK BUSY 




send returned_MPAK_with_ 

ENDIF 


COde: PERSONAL MAN NOT EXIST to 
APP 




WHEN LOGOUT 

remove MPAK. sender from our flexlist 
MPAK. type dependent = MCU MAN 
send MPAK~to transmit to LINK 
next_state «~LINK_BUSY 




WHEN ACTIVE, INACTIVE 

send MPAK to transmit to LINK 
next state ■= LINK BUSY 






send returned_MPAK_with_code: INCORRECT to APP 




ENDCASE 
END_P_check_and_sendJDTESERV 
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2.2.3 P_CHECK_AND_SEND_CSUBCOM 

P_check_and_send CSOBCOM 
CASE MPAK. type 

WHEN CONHEQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST 

MPAK.line = 0 

MPAK. connection identity ~ next MPAK.connection_identity 
SPEECH_REG.part~here = MPAK. sender 
SPEECH_REG.other_part = MPAK. addressee 
SPEECH REG. line = MPAK.line 

SPEECH~REG.conn_id = MPAK.connection_identity 
send MPAK_to_transmit to LINK 
next_state =~sending_conreq 

WHEN DISCON 

send MPAK DISCON with 

MPAK. sender = SPEECH_REG.part_here 
. . MPAK. addressee = SPEECH REG.other_part 
MPAK.line = SPEECH_REG .Tine 

MPAK.connection_identity = SPEECH_REG . conn_id 
send MPAK to transmit to LINK 
next_state '"sending discon 



ignore_signal 



ENDCASE 



: and 5 
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2.3 P_MPAK_TO_RETBANSMIT 






PJMPAK_to_retransmit 






CASE next state 
WHEN idle 

CASH MPAK. class 
WHEN PSUBCOK, PSOSCOM 
P_check_f ormat 
IP format ■ true THEN 

send MPAK to retransmit to LINK 
next state =~LINK BUS* 
ELSE 




send returned MPAK with code : INCORRECT to APP 

ENDIF ~ 
WHEN OTHERWISE 

send returned MPAK with code : INCORRECT to APP 
ENDCASE . ~ 




WHEN die state 

send returned MPAK with code: NOT -SENT DIE 
WHEN wait_for_hook~off normal, ~" 
wait_f or_hook_of f fast r 
wait~far hook aff group 
IF MPAK . class = PSOSCOM THEN 
save signal 
make hook on signal 
P_HOOK_ON_handling 




^send'returned_MPAK_with_code:NOT_SENT_SPEECH to APP 




WHEN sending conreq, sending conrea, speech normal, speech group 
IP MPAK. class = PSOSCOM THEN 
CASE next^state 

WHEN sending conreq, sending conrea 
save_signal 

send order to return' MPAK to LINK 

next_state = stop sending 
WHEN speech_normal, speech group 

save_signal 

raake~hook on signal 

P HOOK ON~handling 
ENDCASE ~ ~ 




ELSE 

send returned MPAK with code: NOT SENT SPEECH 
END IP ~ ~ 
WHEN OTHERWISE 

save_signal 
ENDCASE ~ 
END_P_MPAK_to_retransmit 


3,Ukm 







A 232 SUM 
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2 . 4 P_REC_MPAK_FROM_L INK 




P_HEC_HPAK_FROM_L INK 





activated = TRUE 
CASE MPAK. class 
WHEN PSUBCOM.PSOSCOM 

IP F^get^jrecjnan = MCO_MAN or in flexlist or in grouplist THEN 
send MPAK received to APP 

ELSE 

P_unknown handling normal 

ENDIP ~ 
WHEN CSUBCOM 

P_REC_MPAK_CSUBCOM FROM LINK 
WHEN DTESERV 

IP F_get_rec_man = MCU MAN or in flexlist or in grouplist THEN 
CASE MPAK. state . ~ 
WHEN ak,from_mail 

P_REC_MPAK_DTESERV_FROM LINK_NORMAL 

WHEN OTHERWISE 

CASE MPAK. type 

WHEN • LOGINREQ,SOSRX r VICESOSRX 

send MPAK_received to APP 
WHEN OTHERWISE 
ignore signal 
ENOCASE 
ENDCASE 
ELSE 

P_unknown handling normal 
ENDIF 
ENOCASE 
END_P_REC_MPAK_FROM_LINK 



2.4.1 P_UNKNOWN_HANDL I NG_NORMAL 



P_unknown_handling normal 

CASE next state 

WHEN idle" 

set MPAK . UNKNOWN_F = 1 

send MPAK_to transmit to LINK 

next_state =~link busy 

WHEN die_state 

set MPAK. UNKNOWN F = 1 

send MPAK_to_transmit to LINK 

next state = sending_during die 

WHEN OTHERWISE • ~ 

save_signal 

ENDCASE 

EMD_P_junknown_handling normal 
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2.4.2 P_REC_MPAK_DTESERV_FROH_LINK_NORMAL 

PJREC_MPAK_DTESERV PROM LINK NORMAL 
CASE MPAK . type ~ ~ 
WHEN LOGINGRA 

Add personal subscription MAN to the flexlist 

send MPAK received to APP 
WHEN LOGINREF 

send MPAK_received to APP 
WHEN LOGODTORD 

remove personal subscription MAN from the flexlist 

send MPAK_received to APP 
WHEN DIE 

' IP next_state - idle or die_state THEN 
next_state = die state 
send die to APP ~ 

save signal 
. END ~ 

WHEN LIVE ._ 

IP next_state = idle or die state THEN 
next state = idle ~ 
send~"live to APP 
ELSE 

save_signal 

END 

WHEN GROOPLIST 

replace grouplist 

set grouplist_received flag 

send MPAK_received to APP 

send group list information to data link layer 
WHEN AREALIST 

send area list information to data link layer 
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WHEN ROAMORD / FLEXREQ , INFOREQ , ESNREQ 

IF next_state = idle pr die scate THEN 
CASE MP AK. type 

WHEN ROAMORD make MPAK.type ROAM 
WHEN FLEXREQ make MPAK.type FLEXLIST 
WHEN INFOREQ make MPAK.type INFO 

I ESNREQ make MPAK.type ESNINFO 



send MPAK_to transmit to LINK 
CASE next_state 

WHEN idle next state = link busy 

WHEN die_state next~state = sendTng_during_die 



ELSE 

save signal 

ENDIF " 
WHEN FLEXLIST 

replace flexlist. 

send MPAK received to APP 
.WHEN TIME ~ 

send MPAK_received to APP 
WHEN OTHERWISE 

ignore_signal 
ENDCASE MPAK 
>_P_REC_MPAK_DTESERV_FROM_LINK_NORMAL 
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2.4.2.1 F_GET_REC_MAN 



F_get_rec_man 

CASE MPAK. state 
WHEN ok,from_mail 

F_get_rec_man = MPAK. addressee 
WHEN OTHERWISE 

P_get_rec_raan = MPAK. sender 
ENDCASE MPAK. state 
END_P_get_rec_man 



2.4.3 P_REC_MPAK_CSOBCOM_FROM_LINK 



P_REC_MPAK_CSOBCOM_FROM_L1NK 
CASE next_state ~ 
WHEN idle~ 

P_REC_MPAK CSUBCOM_FROM_LINK_IDLE 
WHiM link_busy, sending during~die,stop sending 

save signal ~ ~ 
WHEN die_state 

P REC_MPAK_CSUBCOM_FROM_LINK_DIE 
WHEN wart_for_hook_off_normal, 
wait_for_hook_off_fast, 
wait_for_haok_off_group 

P_REC_MPAK_CSUBCOM FROM_LINK_WAIT 
WHEN speech normal, speecE_group 

P_REC~MPAK CSUBCOM FROM LINK_SPEECH 
WHEN sending_conreq ~ 

CASE MPAK. type 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST , CONORD 
save_signal 

send order_to_return_MPAK to LINK 
next state = stop sending 
WHEN OTHERWISE 

ignore signal 
ENDCASE MPAK 
WHEN sending_conrea 

IF MPAK. type DISCON THEN 
send MPAK_received to APP 
send order_to_return_MPAK to LINK 
next state = stop sending 
ELSE 

ignore_signal 

send order_to_return_MPAK to LINK 

next state~= stop sending 
ENDIF ~ 
WHEN sending discon 
save_sTgnal 

send order_to_return_MPAK to LINK 
next_state = stop sending 



END_P_REC_MPAK_CSDBCOM_FROM_LINK 
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P_REC_MPAK_CSUBCOM_FROM_LINK IDLE 
CASE MPAK . type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ/ EXTCONHEQ 
CASE MPAK. state 
WHEN Ok 

IP F_get_rec_man = MCU_MAN or in flexlist 
start 60 second timer for hook off 
SPEECH_REG.part_here = MPAK. addressee 
SPEECH_REG.other_part = MPAK. sender 
SPEECH_REG .line = MPAK. line 

SPEECH_REG.conn_id = MPAK.connection_identity 
send MPAK_received to APP 
next_state = wait_for hook_of f_normal 
ELSE 

P_unknown .handling_csubcom 
ENDIP 
WHEN OTHERWISE 

send speech_off to LINK 
ENDCASE MPAK. state 
WHEN CONFAST , ADDCONFAST , SOSCONFAST 
CASE MPAK. state 
WHEN ok 

IF F_get_rec_man = MCD_MAN or in flexlist 
start 10 second timer for hook off 
SPEECH_REG.part_here = MPAK. addressee 
SPEECH_REG. other _Dart = MPAK. sender 
SPEECH_REG . line =" MPAK. line 

SPEECH_REG.conn_id = MPAK.connection_identity 
send MPAK_received to APP 
next_state = wait_for_hook_of f_fast 
send~speech on to LINK 
ELSE 

P unknown handling csubcom 
ENDIF 
WHEN OTHERWISE 

send speech_off to LINK 
ENDCASE MPAK. state 
WHEN CONORD 

CASE MPAK. state 
WHEN ok 

IF F_get rec_raan in grouplist 

start~60 second timer for hook off 
send MPAK_received to APP 
next state = wait_£or_hook_of f_group 
. send~speech_on to LINK 

ELSE 

send speech off to LINK 

E NDIF 
WHEN OTHERWISE 

send speech off to LINK 
ENDCASE MPAK. state 
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WHEN OTHERWISE 

send speech off to LINK 
ENDCASH MPAK 
END_P_REC_HPAK_CSnBCOM_FROMJC.INK_IDLE 



2.4.3.2 P_UNKNOWN_HANDLI NG_.CSUBCOM 



P_unknown handling csubcom 
send~speech_on to LINK 
make MPAK DISCON with 

MPAK. sender = received_MPAK. addressee 
MPAK. addressee = received_MPAK. sender 
MPAK. line = received_MPAK.line 
MPAK.connection_identity = 

received MPAK. connection identity 
MPAK . UNKNOWN_F= 1 ™ 
send MFAK_to_transmit to LINK 
next_state = ..sending^discon 
END_Pjunknown_handling_csubcom 



2.4.3.3 P_REC_MPAK_CSUBCOM_FROM_LINK_DIE 



P_REC_MPAK CSUBCOM FROM LINK DIE 
. CASE MPAK .type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST 
CASE MPAK. state 
WHEN Ok 

send speech_on to LINK 
make MPAK DISCON with 

MPAK. sender = received_MPAK. addressee 
MPAK. addressee = received_MPAK. sender 
MPAK. line = rec'eived_MPAK7line 
MPAK.connection_identity = 

received MPAK. connection identity 
IF F_get_rec man = MCU MAN~or in flexlist 

send MPAK~to transmit to LINK 
ELSE ~ ~ 

set DNKNOWN_F = 1 in MPAK DISCON 
send MPAK to_transmit to LINK 
ENDIF 

next_state = sending_during_die 
WHEN- OTHERWISE 

•send speech off to LINK 
ENDCASE MPAK. state 
WHEN OTHERWISE 

send speech off to LINK 
END_P_REC_MPAK_CSDBCOM~FROM_LINK_DIE 
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P_REC_MPAK_CSUBCOM FROM LINK WAIT 



P_REC_MPAK_CSOBCOM FROM LINK WAIT 
CASE MP AK. type ~ 
WHEN DISCON 

reset hook_off timeout 

send speech off to LINK 

send MPAK_received to APP 

next_state = idle 
WHEN CONORD 

ignore signal 

IF next_state < > wait_for_hook_of fjgroiip • 
reset hook. of f timeout 
send speech_off to LINK 
next state = idle 
make MPAK DISCON 
send MPAK received to APP 

END IF 



END_P_REC_MPAK_CS0BC0M_FROM LINK WAIT 
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P_REC MPAK CSUBCOM FROM LINK SPEECH 



P_REC_MPAK CSUBCOM FROM LINK SPEECH 
CASE MPAK. type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONF AS T , SO S CO N FAS T 
CASE MPAK. state 

WHEN no_transfer, illegal, congest, error , busy 

send speech_off to LINK 

send MPAK received to APP 

next_state = idle 
WHEN OTHERWISE 

ignore signal 

make MPAK DISCON 

send MPAKjreceived to APP 

send speech_off to LINK 

next_state- = idle 
ENDCASE MPAK. state 
WHEN DISCON 

send MPAK received to APP 

send speech_off to LINK 

next state = idle 
WHEN CONORD 

ignore_signal 

IF next_state < > speech_group THEN ■ 
make MPAK DISCON ~ 
send MPAK_received to APP 
send speech_off to LINK 
next_state = idle 

END IF 
WHEN OTHERWISE 

ignore signal 
make MPAK DISCON 
send MPAK_received to APP 
send speech off to LINK 
next_state = idle 



END_P_REC_MPAK CSUBCOM FROM LINK SPEECH 
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2.5 P_MP AK_TRANSMI TTED 

F_MPAK_TRANSMITTED 
activated = TRUE 
CASE MPAK. class 
WHEN PSUBCOM,?SOSCOM,DTESERV 
CASE next_state 
WHEN linkjausy 

next_state = idle 
WHEN sending during die 

next_state = die^state 
ENDCASE 

IP MPAK. UNKNOWN F = 0 THEN 

IP MPAK. class" = DTESERV THEN 
CASE MPAK. type 

WHEN LOGINREQ,SOSRX,VICESOSRX 

send returned_MPAK_with_code:SENT to APP 
WHEN INACT-IVE 

IP power_off THEN 

set power off ready 

ENDIP 

IF manual_mode_on received THEN 
set manual mode 



send returned_MPAK_with_code:SENT to APP 
IP (MPAK. class = PSOBCOM) AND {buff er_full_f lag) 
• make MPAK INACTIVE 
send MPAK to_transmit to LINK 
next_state = link busy 
ENDIP MPAK. class 
ENDIP MPAK. class 
ENDIP MPAK . UNKNOWN F 
I CSUBCOM 

CASE MPAK . type 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 

CONFAST , ADDCONFAS T , SOSCONFAST 

send speech on to LINK 

send returned_MPAK_with_code:SENT to APP 

next state = speech normal 
WHEN CONREA 

send speech on to LINK 

send returned MPAK with code: SENT to APP 



send speech off to LINK 
send returned MPAK_with_code : SENT t o AP P 
IF next_state~= sending_during_die THEN 
next state = die state 



next state =• idle 



ENDCASE MPAK 
ENDCASE MPAK. Class 
END_P_MPAK TRANSMITTED 
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2 . 6 P_MPAK_NOT_TRANSMITTED 




P MPAK HOT TRANSMITTED 




CASE MPAK. class 




WHEN PSOBCOM,PSOSCOM,DTESERV 




CASE next state 




WHEN link_busy 




next state = idle 




WHEN sending during die 




next state « die state . 


WHEN stop_sending 




next state = idle 




ENDCASE ~ 




IF MPAK. UNKNOWN F = 0 TH 


EN 


IE MPAK. class = DTESE 


RV THEN 


CASE MPAK. type 




WHEN LOGINREQ,S0SRX,VICES0SRX 


send returned MPAK with code: NOT SENT to APP 


WHEN INACTIVE 




IP power off 


THEN 


set power off ready 


ENDIP 




IP manual mo 


de on received THEN 


set manual mode 


ENDIP 




ENDCASE 

ELSE 




send returned MPAK with coderNOT SENT to APP 


ENDIP MPAK. class 




ENDIP MPAK. UNKNOWN F 




WHEN CSOBCOM 




CASE MPAK . type 




WHEN CONREQ , ADDCONREQ , SOSCONR 


EQ,EXTCONREQ, 


CONFAST , ADDCONFAST , SOSCONFAST 


IP next state = sending conreq THEN 


send speech off to LINK 


next state ■ idle 

uiium nmmcTi 




send speech off to LINK 


next state = idle 




WHEN DISCON 




send speech off to LINK 


IP next state = sending during die THEN 


next_state = die_state 
ELSE "" 


next state = idle 


ENDIP 




ENDCASE MPAK 




send returned MPAK with code: NOT SENT to APP 


ENDCASE MPAK. class 




END_P_MP AK_NOT_TRANSMI TTED 









A.J31SUM 
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2.7 P_HOOK_ON_HANDLING 



P_HOOK_ON_handling 
CASE next_state 

WHEN wait for_hook_off_normal, 
wa i t~f o r_hook_o f f _f ast , 
wait~forJiook~off_grOup 

~ reset hook_o£f timeout 
P_t imeout_ha nd 1 i ng 

WHEN sending_conreq,sending_conrea 
save_signal 

send order_to_return_MPAK to LINK 
next_state = stop_sending 

WHEN speech_normal 

make MPAK .DISCON with 

MP AK. sender = SPEECH_REG.part_here 
MPAK. addressee = SPEECH_REG.other_part 

MPAK. line = SPEECH_REG, line 

MPAK.connection_identity = SPEECH_REG . conn_id 
send MPAK_to_transmit - to LINK 
next_state =~"sending_discon 

WHEN speech_group 

""send speech_off to LINK 
next_state = idle 

WHEN idle 

IF line connection request received THEN 
make MPAK DISCON with 

MPAK. sender = SPEECH_REG.part_here 
MPAK. addressee = SPEECH REG.otherjpart 
MPAK. line = SPEECH_REG . Tine 

MPAK.connectionj.dentity = SPEECH_REG.conn_id 
send MPAK_to_transmi't to LINK 
next state = sending_discon 
ELSE 

ignore signal 
ENDIF 
WHEN OTHERWISE 

ignore_signal 
ENDCASE next_state~ 
END P HOOK ON handling 



Exhibit 2, p. 442 



Cartel Mohitex- 



53/1056-A 296 5171/2 De 



2.8 PJDIMEOUT_HANDLING 

P_t imeou t_handl ing 
CASE next_state 

WHEN wait_f or_hook_of f_normal , waifc_f or_hook_of f_f ast 
send speech_on ta LINK ~ 
make MPAK DISCON with 

MPAK. sender = SPEECHJREG.partjiere 
MPAK. addressee = SPEECH_R£G.other_part 
MPAK. line = SPEECH_REG. line 

MPAK. connect ion_identity = SPEECH_REG.conn_id 
send MPAK_to_transrait to LINK 
next_stati" =~sending_discon 

WHEN wait_for_hook_pff_group 
send speech_off to LINK 
next_state = idle 

WHEN OTHERWISE 

ignore_signal 
ENDCASE next_state 
END_P_t imeou tjiandli ng 



2.9 P_HOOK_OFF_HANDLING 



P_HOOK_OFFJiandling 
CASE next_state 
WHEN wait_for hook_ofE normal 
reset hook off timeout 
make MPAK CONREA with 

MPAK. sender = SPEECH_REG . par t_he r e 
MPAK. addressee = SPEECH_REG.other_part 
MPAK. line = SPEECH_REG . line 

MPAK.connection_identity = SPEECH_REG.conn_id 
send MPAK_to transmit to LINK 
next_state =~sending_conrea 

WHEN wait for_hook off fast 
r_esi"t hook_of"f timeout 
next_state = speech_normal 

WHEN wait_for_hook_off group 
reset hook_off timeout 
next_state = speech_group 

WHEN OTHERWISE 

ignore_signal 
IE next state 
END_P_HOOK_OFF_handling 
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2.10 P_ROAMING HANDLING 



P_roaming_handling 

IP next_state « idle or die_state 
IP grouplist received flag THE 

make MPAK ROAM ~ 
.ELSE 

make MPAK BORN 
END IF 

send MPAK_to transmit to LINK 
CASE next state 
WHEN idle - 



next_state = sending_during_die 



save signal 

IDIF ~ 

ID_P_roaming_handling 
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2 . 11 P_ACTIVATION_HANDLING 




P activation handling 

IP HOT buffer full flag THEN 
activated = — FALSE 

start activation timer with «active_delay_power_pn' 
ENDIF 

END_P_activation_handling 


2 . 12 P_ACTIVATION_HANDLING_LINK 




P activation handling link 

IP NOT buffer full flag THEN 
activated = FALSE - 

start activation timer with 'active delay lost_contact' 


END_P_act iva t ionjiandli ngJLink 




2.13 P_ACTIVATION_TIMEOOT_HANDLING 


P activation timeout handling 

IP next state =-iale or die state THEN 
IP NOT activated THEN 
make MPAK ACTIVE 
. send MPAK to transmit to LINK 
CASE next state 
WHEN idle" 

' next state = link busy 
WHEN die_state 

next state = sending during die 
ENDCASE 


ELSE 

save signal 
ENDIF ~ 
END_P_activation_timeout_handling 
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2.14 P_POWER_OFF HANDLING 



P_power_o£f_handling 
power_off received 
start~power_o£f timer 
CASE next state 
WHEN idle- 
make- MPAK INACTIVE 

send MPAK_to transmit to LINK 

next_state =~link busy 
WHEN die_state _ 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state = sending during_die 
WHEN speech_normal,speech_group,wait_£or_hook_off_normal, 
wait_£or_hook_off_fast,wait_for_hook_off_groITp, 
sendTng_conrea, sending jdiscon,sending_conreq 

disconnect the speech (according to current state) 

make MPAK INACTIVE 

send MPAK_to_transmit to. LINK 

next_state = link busy 
WHEN OTHERWISE ' 

save signal 
ENDCASE 
END_P jpower_of f _handl i ng 



2.15 P MANUAL MODE ON HANDLING 



Pjnanual_mode_on_handling 
manual_mode_on received 
start raanual_mode_on_timer 
CASE next state ~ ~ 
WHEN idle" 

make MPAK INACTIVE 

send MPAK_to transmit to LINK 

next_state =~link_busy 
WHEN die state 

make MPAK INACTIVE 

send MPAK_to_t ransrai t to LINK 

next_state = sending_during_die 
WHEN speech normal, speech group, wait f or_hook_o£f _norraal , 
wait_f or_hook_of f_f ait , wait_for"hook_off "group, 
sending_conr ea , sending_discon , sending_conr eq 

disconnect the speech (according to current state) 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 
next_.state ="link_busy 



save signal 
MDCASE 

»_P_manual_mode_on_handling 
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2.16 P BUFFER FULL HANDLING 



P_buf f er_f ulljtiandling 
CASE next_state 
WHEN idle 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state =~link_busy 
WHEN die state 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state = sending_during_die 
WHEN speech_normal,speech_^group,wait for hook_of f_normal, 
wait for hook off_f ast,wait_for~hook_of f_group, 
sendTng_conrea,sending_discon, sending conreq 

disconnect the speech (according to current state) 

make MPAK INACTIVE •• 

send MPAK_to_transmit to LINK 

next_state = link busy 



save_signal 



send buffer full to APP 
set buffer_iull_flag 

END_P_buffer_full_handling 
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3 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 

Reference Section 

Rl-01 •■ Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 — Terminology 

Rl-05 References 

Rl-06. Network operator information 

Rl-08 Application layer 

Rl-09 ' Network layer 

Rl-ll Interface requirements, fixed terminals 

Rl-1'2 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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ABSTRACT 



This document is a specification of the interface for a 
fixed terminal with HDLC interface, connected to the 
MOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions and secondary station in HDLC. 

CCITT recommendation X.21 bis is used at the physical 
layer and HDLC is used at the link layer. The network 
layer consists -of MPAK's according to reference Rl-09. 
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2 PHYSICAL LAYER 



Connection is in accordance with CCITT recommendation X.21 
bis. 



2.2 B URATE 



For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 



3 . 1 GENERAL 



The design of the link layer follows ISO standards "High 
level data link control" {HDLC) • See ISO 3309-1984, ISO 
4335-1984 and ISO 7809-1984 for reference. 



3.2 SUB-SET OP HDLC 

HDLC is a comprehensive catalogue of standards for link 
control. The ONC 12 class, i.e. "Unbalanced operation, 
normal response mode" with added test function, of 
procedure is used for the link layer. 

The MOBITEX network is the primary station and the fixed 
terminal is the secondary station. 



3.2.1 Clarification 

3.2.1.1 Commands and responses 

The following commands and responses are obtained with the 
above class: 



Command from 
. network 


Response from 
fixed terminal 


I 

RR 


I 

RR 


RNR 
SNRM 


RNR 
UA 


DISC 


DM 




FRMR 


TEST 


TEST 



A frame can be up to 566 octets including start and stop 
flag. This will allow 560 octets in an information field 
in an I frame. 
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3.2.1.3 ' The use of the address field 

The address field comprises one octet. The address in the 
address field shall be adjustable. The factory set address 
shall be 11000000 (bit 1...8). 

Address 11111111 is defined as the all-station address and 
thus all receiving data stations shall accept and action 
the associated frame. If the P bit is set in such a frame, 
the terminal shall reply with its own address as reply 
address. 



3.2.1.4 FRMR responses 

The information field in an FRMR response shall be padded 
with zeros so .the length will be 3 octets. 

3.2.1.5 TEST -frames 

. TEST frames can contain an information field. The maximum 
length of that field is the same as' for I-frames. 

TEST frames can be' transmitted and received both in NRM 
and ndm. 
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3.3 OPERATING MODES FOR THE LINK LAYER 

The link layer shall be able to assume the following 
modes : 

o Normal resanse mode (NRM) according to ISO 4335 item 
5.1.1. 

o Normal disconnected mode (NDH) according to ISO 4335' 
items 5.2 and 5.2.1. 

A terminal's capacity in NDH is limited to: 

- accepting the mode setting commands (SNRM or DISC) 

- accepting and responding to a test command 

- transmitting DM or TEST at a respond opportunity 

A terminal- may only -change - to NRM from NDM by accepting an 
SNRM command from the network. 

A terminal can change from NRM to NDM by accepting a DISC 
command from the network or through manual restart of the 
link control. NDM shall be the initial mode when power is 
switched on or when restarting the terminal. 
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3.4 CONNECTION AND DISCONNECTION PROCEDURE 

The link is connected in accordance with ISO 7809 item 
3.4.1.1. The network transmits SNRM to the terminal. If 
there is no reply, the SNRM is retransmitted until an UA 
reply is received. 

Normal disconnection of the link is in accordance with ISO 
7808, item 3.4.1.2. If there is no reply from the 
terminal, DISC is retransmitted. This is repeated no more 
than 10 times or until an DA reply is. received. The link 
is then assumed to be disconnected and the connection at 
the lower level can be broken. 

If there are no frames to send, the link layer shall send 
flags cotitinuosly as soon as the physical layer is in data 
transmission mode. 



3.5 TIME-OUT 

When the terminal receives a correct frame with the P bit 
set to "1" (one), the reply shall commence within 50 ms. 
The time is calculated from when the last bit of the 
command's closing flag is received until the first bit of 
the response is transmitted. 

If several frames are transmitted in sequence, the time 
between them shall not exceed 50 ms. This time is 
calculated from the last bit of a frame's closing flag to 
the first bit of the next frame's opening flag. 

The terminal has no time-out function for recovery in the 
event of a link fault. The terminal however may have time- 
out function to inform the operator about a link fault. 
The time-out may not be less than 45s in NRM and 120 s in 
NDR. 



3.6 RECOVERY FROM FADXT CONDITION 

All recovery from a fault condition is carried out by the 
network. The terminal is first ordered to NDM and then to 
NRM. 
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4 MOB I TEX TERMINAL •SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 

Reference Section 

Rl-01 --Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

. Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series X, 1984 Edition (Red 
Book) X.21 bis 



ISO-standards: 



ISO 3309-1984(E) 
ISO 4335-1984 (E) 
ISO 7809-1984(E) 
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ABSTRACT 

This document is a specification of the interface for a 
fixed terminal with X.25 interface, connected to the 
MOBITEX network. 



Exhibit 2, p. 460 



Cantel Mobitex- 



1055 - A 296 5491 Oe 

^■te TtTT-. 

1990-02-26 C MTS11X25.1 



TABLE OF CONTENTS 



1 INTRODUCTION 3 

1.1 GENERAL 3 

2 PHYSICAL LAYER , 4 

2.1 GENERAL 4 

2.2 BITRATE 4 

3 LINK LAYER 5 

4 PACKET LAYER 6 

4.1 Diagnostic codes , .• 8 

5 MOBITEX NETWORK LAYER 10 

6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 11 



Exhibit 2, p. 461 



CantelMobitex- 



1056 - A 296 5491 Ue 

ac-aw nrz; 

1990-02-26 C MTS11X25.1 



1 INTRODUCTION 



1.1 GENERAL 

The designation 'terminal' for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions for X.25 packet layer and link layer. 

Connection of a terminal with X.25-interface can be done 
directly to the MOBITEX network or through an X.25 
network. 

CCITT recommendation X.21 bis is used at the physical 
layer, LAPB is used at the link layer and X.25 is used at 
the packet layer. 

The user data in X.25 packet layer should contain HPAKs as 
_ Aescribed^ in .reference Rl-09. 
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2 PHYSICAL LAYER 



Connection is in accordance with CCITT recommendation 
X.21 bis. 



2.2 . BITRATE 

For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 

The design of the link layer follows LAPB, Link Access 
Procedure Balanced, according to CCITT recommendation 
X.25. 

The extended format modulo 128 is not supported. 
The multilink procedure MLP is not supported. 
Timeout period is Tl=3 seconds. 
Maximum number of outstanding frames are K=7. 
Number of retransmission attempts are N2=10. 
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4 PACKET LAYER 



The design of the packet layer follows CCITT 
recommendation X.25 for DTE with the following 
restrictions: 

When the terminal is using direct connection there is only 
one logical channel. The logical channel group number 
should be zero and the -logical channel number should be 
one. 

When connection is made through an X.25 network, maximum 
number of logical channels are 8. 

The delivery-bit should be set to zero in all data, 
packets. 

The qualifier-bit is ignored by the MOBITEX network. 

The sequence numbering scheme of the data packets is 
performed modulo 8. 

The standard default value for the window size is two 
packets, it is possible to change the default window size 
to 1, 3, 4, 5, 6 or 7 packets. 

The standard default value for the packet size is 128 
octets. It is possible to change the default packet size 
to 32, 64, 256, or 512 octets. 

Interrupt, reject and registration packets are not 
supported. 

The following facilities are supported: 

- Plow control parameter negotiation. 

- Non standard default packet size. 

- Non standard default window size. 

- Reverse charging. (See note 1.) 

- Reverse charging acceptance. (See note 1.) 

A connected terminal can communicate with MOBITEX through 
a permanent virtual circuit (PVC) or through a virtual 
circuit (VC). 
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If no packets, in either direction, has been transmitted 
on the logical channel during X (default 4 and possible to 
change) minutes a virtual call will be cleared by the 
MOBITEX network if the connection is VC. 

Note 1 : Only used when connected through an X.25 network. 

The packet call request/incoming call and call accepted/ 
call connected should contain both calling DTE address and 
called DTE address (optional in CCITT X.25). 
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4.1 Diagnostic codes 

Coding of the restarting cause field and the diagnostic 
code field in a restart packet, used by the MOBITEX 
network and the connected terminal. 



c ause diagn. explanation 

- 00 local procedure error 

17 invalid packet type for state rl 

52 time expired for restart indication 

07 network operational 



Coding of the clearing cause field and the diagnostic code 
field in a clear packet, used by the MOBITEX network and 
the connected .terminal. 

cause diagn. - explanation 

0 dte originated 
0 dte clearing 

01 number busy 

72 call collision 

03 invalid facility request 

65 facility code not allowed 

66 facility parameter not allowed 



19 local procedure error' 

20 invalid packet type for state pi 

21 invalid packet type for state p2 

22 invalid packet type for state p3 
24 invalid packet type for state p4 
26 invalid packet type for state p6 
33 unidentifiable packet 

38 packet too short 

41 restart with nonzero in bits 1-4 in octet 
1 or nonzero in bits 1-8 in octet 2 

49 time expired for incoming call 

50 time expired for clear indication 

51 time expired for reset indication 

67 invalid called address 

68 invalid calling address 

69 invalid facility length 
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Coding of the resetting cause field and the diagnostic 
code field in a reset packet , used by the MOBITEX network 
and the connected terminal. 

cause diaqn. explanation 

05 local procedure error 

01 invalid p(s) 

02 invalid p(r) 

27 invalid packet type for state dl 

32 packet type not allowed (registration or 

interrupt packet) 
35 invalid packet type oh pvc channel 

37 reject packet not subscribed 

41 restart with nonzero in bits 1-4 in octet 

1 or nonzero in bits 1-8 in octet 2 
51 time expired for reset indication 



Coding of the diagnostic code field in a diagnostic 
packet, used by the MOBITEX network and the connected 
terminal. 



diaqn. explanation 

36 packet on unassigned logical channel 

38 packet too short 

40 invalid general format identifier 

50 time expired for clear indication 

51 time expired for reset indication 

52 time expired for restart indication 
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5 MOBITEX NETWOP.K LAYER 

The MPAK should be placed in the user data field in one or 
more X.25 data packets. An MPAK should be handled as a' 
complete packet sequence, according to CCITT's X.25 
recommendation # 4.3.5. 

Note: The D-bit should always be set to zero in 
communication with the MOBITEX network. 

If the transmission of an MPAK is interrupted by a 
restart, reset or clear procedure the whole MPAK should be 
retransmitted. 
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6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 3 



Below are the reference designations listed. 

Reference Section 

Rl-01 . Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 " Network operator information 

Rl-08 Application layer 

Rl-09 • Network layer 

Rl-ll Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 



CCITT recommendations series X, 1984 edition (Red. 
book) X.25 and X.21 bis 
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ABSTRACT 

This document is a specification of the interface for a 
fixed terminal with binary synchronous communication (BSC) 
interface, connected to the HOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions. 

CCITT recommendation X.21 bis is used at the physical 
layer. The link layer is IBM's BSC (binary synchronous 
communication), see chapter 2. 

The network layer is a character oriented MPAK (BSCPAK), 
see chapter 4. 
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2 PHYSICAL LAYER 



2.1 GENERAL 



Connection is in accordance with CCITT recommendation X.21 
bis. 



2.2 BITRATE 

For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 

The design of the link layer follows IBM General 
Information - Binary Synchronous communications, GA27-3004 
with the following restrictions: 

Point-to-point connection is used. The Mobitex network has 
a retry timeout of 3 seconds. 

ITB and RVI will be handled by the Mobitex network when, 
received, but is never transmitted. 

Transparent mode is not handled by the Mobitex network. 

SOH can be received but the content of the header is not 
interpreted. SOH is never transmitted. 

The Mobitex network retransmits max 15 times. 
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4 NETWORK LAYER 

The network layer use BSCPAK. A BSCPAK is a character- 
oriented MPAK, HPAKs are bit-oriented and are described in 
reference Rl-09. 

BSCPAK is EBCDIC-coded , see chapter 6. 

All MPAK, except MPAK DATA, HPDATA and EXTPAK can be 
translated to BSCPAK. 

Sendlist is not handled. 

All numeric fields are right adjusted with preceding 
zeroes. 

BSCPAK shall be handled in the same way as corresponding 
MPAK. 

Maximum length for a BSCPAK is 548 octets (BSCPAK TEXT 
without sendlist) . 

A BSCPAK may be divided into several blocks, each of which 
ends with ETB except the last one which ends with ETX. 

The content of the text field in a BSC-block is a BSCPAK 
(or part of BSCPAK) in either direction, to or from the 
Mobitex network. 

STX precedes and ETX ends a BSCPAK. 
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5 SPECIFICATION OF BSCPAK 

BSCPAK shall be handled, according to reference Rl-09, in 
the same way as corresponding MPAK. Below is a description 
of the translation between bit-oriented MPAK and the 
character oriented BSCPAK. 

All BSCPAKs consist of one BSCPAK header and one part with 
typedependent components . 

All characters in a BSCPAK shall be in EBCDIC code. 



BSCPAK, COMMON COMPONENTS 



BSCPAK-field 
sender 
adressee 

_ciass .. , .... . 
extern_F 
type ~ • 
mailbox F 
digital~F 
sendlist_F 
unknown_F 
reserve_F 
trafstate 

Length 26 octets. 



Ex. sender = 123456 

octet 1 



octet comment 



1- 8 


only digits 


9-16 


only digits 


17 


only digits 


18 


0 or 1 


19-20 


only digits 


21 


0 or 1 


22 


0 or 1 


23 


0 


24 


0 or 1 (0 from Mobitex) 


25 


0 


26 


0 ... 7 (0 to Mobitex) 



Octet 1 will be transmitted first. 
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5.2 BSCPAK COMPONENTS 

The following components are described in this chapter: 

TEXT 

STATOS 

SOSINFO 

SOSACK 

CONREQ 

SOSCONREQ 

ADDCONREQ 

CONGRA 

CONORD 

CONREA 

DISCON 

EXTCONREQ 

CLOOPON 

CLOOPOFF 

LOGINREQ 

LOGINGRA 

LOGINREF 

LOGOUT 

LOGOOTORD 

ACTIVE 

INACTIVE 

DIE 

LIVE 

VICESOSRX 

SOSRX 

GROOPLIST 

FLEXREQ 

PLEXLIST 

TIME 



A292S1533 
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* TEXT without adress list: 
BSCPAK-field octet comment 



bscpak-header 

time 

text 



Length 37-548 octets. 



1-26 

27-36 decimal digits (YYMMDDHHMM) 
37- all characters included in 
Mobitex textcode (EBCDIC- 
coded), 1-512 characters 



* STATUS without adress list: 
BSCPAK-field octet comment 



bscpak-header 
time 

status code 
Length 39 octets. 



1-26 

27-36 decimal digits (YYMMDDHHMM) 
37-39 only digits 000 ... 255 



SOSINFO 
BSCPAK-field 



bscpak-header 
time 

static emergency 
information 



dynamic emergency 
information 



Length 36-548 octets. 



27-36 decimal digits (YYMMDDHHMM) 

37- all characters included in 
Mobitex textcode (EBCDIC- 
coded), 0-256 characters 

'37- all characters' included in 
Mobitex textcode (EBCDIC- 
coded), 0-256 characters 



* SOSACK 
BSCPAK-field 



octet comment 



bscpak-header 1-26 

time 27-36 decimal digits" (YYMMDDHHMM) 
emergency 

acknowledgement status 37-39 decimal digits 000.. 255 
Length 39 octets. 
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CONREQ 
BSCPAK-field 



octet comment 



bscpak-header 
line number 

connection identity 

Length 32 octets. 



1-26 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 



BSCPAK-field 



bscpak-header 
line number 



connection identity 
Length 32 octets. 



octet comment 



1-26 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 



ADDCONREQ 
BSCPAK-field 



bscpak-header 
line number 



1-26 
27-29 



decimal digits 000.. 255 
(000 from terminal) 
decimal digits 000.. 255. 



connection identity 30-32 „ 

additional information 33-52 all characters included in 
Mobitex textcode (EBCDIC- 



Length 52 octets. 



CONGRA 
BSCPAK-field 



octet comment 



bscpak-header 
line number 

connection identity 

Length 32 octets. 



1-26' 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 
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* CONORD 
BSCPAK-field 


octet 


comment 


bscpak-header 


1 


-26 




line number 


27 


-29 


decimal digits 00O..255 








(000 from terminal) 


connection identity 


30 


-32 


decimal digits 000.. 255 


Length 32 octets. 








* CONREA 
BSCPAK-field 


octet 


comment 


bscpak-header 


l 


-26 




line number 


27 


-29 


decimal digits 000.. 255 


- 






(000 from terminal) 


connection identity 


30 


-32 


decimal digits 00.0.. 255 


Length 32 octets. 








* D I SCON 








BSCPAK-field 


octet 


comment 


bscpaic-header 


1 


-26 




line number 


27 


-29 


decimal, digits 000.. 255 








(000 from terminal) 


connection identity 


30 


-32 


decimal digits 000.. 255 


Length 32 octets. 








* EXTCONREQ 








oaLr ak— r le la 


octet 


comment 


bscpak-header 


1 


-26 




line number 


27 


-29 


decimal digits 000.. 255 








(000 from terminal) 


connection identity 


30 


-32 


decimal digits 000.. 255 


subscr. no. in ext. 








network 


33 


-52 


decimal digits 


Length 52 octets. 








* CLOOPON 








BSCPAK-field 


octet 


comment 


bscpak-header 


1 


-26 




line number 


27 


-29 


decimal digits 000.. 255 








(000 from terminal) 


Length 29 octets. 
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* CLOOPOFF 








BSCPAK-field 


octet 


comment 


bscpak-header 
11ns numbs r 


1 
27 


-26 

-29 


decimal digits 000.. 255 
(000 from terminal) 


• Length 29 octets. 








* LOGINREQ 








BSCPAK-field 


octet 


comment 


bscpak-header 
MAN 

password 


1 
27 
35 


-26 
-34 
-42 


only decimal digits 
all characters included in 
Mobitex textcode { EBCDIC- 
coded) 


Length 42 octets. 








* LOGXNGRA 








BSCPAK-field 


octet 


comment 


bscDak-header 
HAN 


1-26 
27-34 


only decimal digits ■ 


Length 34 octets. 








* LOGINREF 








BSCPAK-field 


octet 


comment 


bscpak-header 
MAN 


l 
27 


-26 
-34 


only decimal digits 


Length 34 octets. 








* LOGOUT 








BSCPAK-field 


octet 


comment 


bscpak-header 
MAN 


1 
27 


-26 

-34 


only decimal digits 


Length 34 octets. 
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* LOGOUTORD 






BSCPAK— f ield 


octet comment 


bscpak-header 
HAN 


1-26 

27-34 only decimal digits 


Length 34 octets. 






* ACTIVE 






BSCPAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets. 






* INACTIVE 






BSCEAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets* 






* DIE 






BSCPAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets • 






* LIVE 






BSCPAK-field 


octet comment 


bscpak-header 


1 


-26 


Length 26 octets. 






* VICESOSRX 






BSCPAK-field 


octet comment 


bscpak-header 


1 


-26 


Length 26 octets. 






* SOSRX 
BSCPAK-field 


octet comment 


bscpak-header 


1-26 


Length 26 octets. 
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GROOPLIST 
BSCPAK-field 



bscpak-header 

number of HAM 

MAN 1 

MAN 2 

MAN 3 

MAN 4 

MAN 5 

MAN 6 

MAN 7 

MAN 8 

MAN 9 

MAN 10 

MAN 11 

MAN 12 

MAN 13 

MAN 14 

MAN 15 

Length 148 octets. 



octet comment 



"T=2T 
27-28 
29- 36 
37- 44 
45- 52 
53- 60 
61- 68 
69- 76 
77- 84 
85- 92 
93-100 
101-108 
109-116 
117-124 
125-132 
133-140 
141-148 



1..15 

only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 
only decimal 



digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 
digits 



FLEKREQ 
BSCPAK-field 



bscpak-header 
Length 26 octets. 



octet comment 



: FLEXLIST 
BSCPAK-field 



bscpak-header 

number of MAN 

MAN 1 

MAN 2 

MAN 3 

MAN 4 

MAN 5 

MAN 6 

MAN 7 

Length 83 octets. 



•octet comment 



T=2T 

27 " 1..7 

28-35 only decimal 

36-43 only decimal 

44-51 only decimal 

52-59 only decimal 

60-67 only decimal 

68-75 only decimal 

76-83 only decimal 



digits 
digits 
digits 
digits 
digits 
digits 
digits • 



TIME 
BSCPAK-field 



bscpak-header 
time 



Length 36 octets. 



octet comment 



27-36 decimal digits (YYMMDDHHMM) 
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6 TRANSLATION BETWEEN ASCII AND EDCDIC 



ASCII EBCDIC 



09 


05 


OA 


25 


DC 


or 




on 




an 






22 


7F 


23 


7B 


24 


5B 




g 


26 


50 


27 


_ 










2A. 




2B 




2C 


g 


2D 


60 


2E 


4B 


2F 


61 


30 


FO 


31 


Fl 


32 


F2 


33 


F3 


34 


F4 


35 


F5 


36 


F6 


37 


F7 


38 


F8 


39 


F9 


3A 


7A 


3B 


5E 


3C 


4C 


3D 


7E 


3E 


6E 


3F 


6F 


40 


7C 


41 


CI 


42 


C2 


43 


C3 


44 


C4 


45 


C5 


46 


C6 


47 


C7 


48 


C8 


49 


C9 


4A 


Dl 


4B 


D2 


4C 


D3 


4D 


D4 


•4E 


D5 
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52 
53 



58 
59 
5A 
5B 
5C 
5D 
5E 
5F 



E5 
E6 



62 

63 



71 
72 
73 
74 
75 



89 
91 



95 
96 



7A 
7B 
7C 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references , made to ■ 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
. referred to several times on the same page. 

Rl-06, 4 
Rl-09, 6, 7 



Below are the reference designations listed. 
Reference Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 • 
' Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 



The following references are made in this document: 

CCITT recommendations series V, 1984 Edition(Red 
books )X. 21 bis. 

IBM General Information - Binary Synchronous 
Communications, GA27-3004. 



Exhibit 2, p. 487 



REQUIREMENT SPECIFICATION 1(7) 



Uppcore ■ PriMiwi 

1988 ET/SYS PES 


ET/SYS PES 


1056 - A 296 5516 Oe 


Oa«ini»<jo(i]u«i . Ope rapeuipgravK 

ET/SYSC SUTSlT 


o^rss is*. ivu ?==. - ■ 

1990-02-26 D | MTS11MASC.1 


Cantel Mobitex- 


HOBITEX 

MASC interface 

Fixed terminal 



ABSTRACT 



This document is a specification of the interface for a 
fixed terminal with MOBITEX Asynchronus Communication 
(MASC) interface, connected to the MOBITEX network. 
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INTRODUCTION 



1.1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network correspond to DTE in CCITT recommenda- 
tions . 

CCITT recommendation V.24 is used at the physical layer 
and MASC interface is used at. the link layer (reference 
Rl-19 is used for link layer MASC). The network layer 
consists of MPAK's according to reference Rl-09.. 
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2 PHYSICAL LAYER 



2.1 



GENERAL 



Connection is in accordance with CCITT recommendation 
V.24/V.28. 

Hote: The physical layer of MASC is not directly 

compatible with the physical layer in the masc 
interface of a mobile terminal. 

However this can be done by connecting the Eollowing 
signals in the mobile unit. 



2.2 BITRATE 

For information about permitted bitrate transmission 
rates, please see reference Rl-06. 




A 292 51533 
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3 LINK LAYER 



3 . 1 GENERAL 

The link layer sends, controls and acknowledge information 
between .network and terminal. When faults are detected, 
the link layer handles retransmission. 

The design of the link layer follows PROTOCOL FOR MASC 
TYPE TERMINALS , which is described in 'reference Rl-19. 

The data in information frame is MOB I TEX packets (MPAK) 
which are described in reference Rl-09. 



3.2 FRAMES USED IN MASC 

There are two different types of frames, control frames 
and information frames {see reference Rl-19). 

The following control frames are used: 

- ACK Acknowledgement 

- NACK Negative acknowledgement 

- RACK Request for repetition of the latest sent 

ACK 

- SENS Communication link control 

- SACK Acknowledgement of a received SENS 



Note: The network will not send the frame SENS by 
default. 



Information frames. are used with the following commands: 

- B parameters in machine interface 

- M send/receive MPAK 

- E answer to an invalid command 

- F P terminal MAN request and answer 

- F Q raasc device identity 
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3.3 TIMEOUT 



The masc interface uses two timers, which are described in 
reference Rl-19. 

Note: The network will handle the "30 seconds timeout" as 
follows: 

If no answer is received within 30 seconds/ the 
network will return the frame to the sender. The 
network will then try to start up the line with a B- 
command. 



3.4 START WITH NO SUBSCRIPTION NUMBER 

The terminal has the possibility to ask the network about 
the valid subscription number. When the line is in the 
connected mode, the terminal can ask the network about 
MOBITEX subscription number. 

The terminal sends the P P command and receives the answer 
P PMAN from the network. The terminal will also receive an 
identification of the network in the F Q command. 

F P and F Q are described in reference Rl-19. 
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4 HOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 3, 5 
Rl-19, 3, 5, 6 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 HOBITEX System description 

.-R1-G3 .• < General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series V, 1984 Edition (Red 
books) V.24 and V.28 
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MOBITEX 

Asynchronous interface 
Fixed terminal- MP AD 



ABSTRACT 

This document describes the connection of an asynchronous 
terminal to the MP AD service in the MOBITEX network. 
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TABLE OF CONTESTS 



1 INTRODUCTION 3 

1.1 GENERAL 3 

2 PHYSICAL LAYER • 4 

2.1 GENERAL • 4 

2.2 TERMINAL EQUIPMENT 4 

2.3 PRINTER EQUIPMENT (optional) 4 

2.4 BITRATE 4 

3 PROTOCOL FOR TERMINAL 5 

3.1 CONTROL SEQUENCES FROM TERMINAL TO MPAD 6 

3.2 CONTROL SEQUENCES FROM MPAD TO TERMINAL V 6 
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1 INTRODPCTION 



1.1 GENERAL 



The MP AD communicates with the terminal one character at a 
time with a start-stop protocol. The purpose with the MP AD 
service is to let customers use a standard terminal for 
communication with the MOBITEX network. 

The designation "terminal" for a fixed termial in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions . 
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2 PHYSICAL LAYER 



2.1 GENERAL 

Connection is in accordance with CCITT recommendations 
V.24/V.28. 



2.2 TERMINAL EQUIPMENT 

An asynchronous terminal of start-stop type for serial 
data transmission is used. The communication uses 1 start 
bit, 8 data bits, 1 stop bit and no parity. The screen 
should be 24 lines x 80 columns. The terminal should have 
an advanced video option installed to use the reversed 
video facility. 

If the MPAD-connected terminal has a printer port or 
auxiliary -port, a printer can be connected to this port. 
Messages to/from the terminal can be directed to this 
printer if the terminal can interpret the printer-port 
setting commands described in chapter 3. 



2.3 PRINTER EQUIPMENT {optional) 

The printer should have at least 24 columns, preferably 80 
columns width. The transmission rate and communication 
type depends on the available printer-port on the 
terminal. The printer should be able to use the same 
character-set as the terminal, see chapter 3. 



2 . 4 BITRATE 

For information about permitted transmission rates, 
refer to. reference Rl-06. 



Exhibit 



2, p. 498 



Cantel Mobitex- 



1056 - A 296 5454 tie 

MTS11MPAD.1 



3 PROTOCOL FOR TERMINAL 

The terminal should comply with ANSI/VT100 according to 
the following specifications that is a subset of ANSI 
X3.41 1974 and ANSI X3.64 1979. 

The terminal should be able to : 

* transmit and receive all characters described in 
MOBITEX text code (please refer to reference Rl-06). 

* transmit ASCII-character 127 (DEL). 

* receive ASCII-character 7 (bell) and then give an 
audible signal. 

* receive ASCII-character 10 (LF) and then do a line- 
feed. 

* receive ASCII-character 13 (CR) and then do a 
carriage return. 



interpret the control sequences described in chapter 
3.2 
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3.1 CONTROL SEQUENCES FROM TERMINAL TO MP AD 

The following control sequences should preferably be 
generated by arrow-marked keys. 

ESC O A (arrow up) 

ESC 0 B (arrow down) 

ESC O C (arrow right) 

ESC O D (arrow left) 

The following control sequences should preferably be 
generated by the keys on an auxiliary keypad. 

ESC Op (0) 

ESC 0 q (1) 

ESC O r (2) 

ESC 0 s . (3) 

ESC O t (4) 

ESC 0 u .(5) 

ESC 0 v (6) 

ESC O w (7) 

ESC OX (8) 

ESC O y (9) 

ESC 0 m (dash) 

ESC 0 1 (^lowercase E) (comma) 

ESC 0 n (period) 

ESC 0 M (ENTER) 

ESC 0 P (PF1) 

ESC 0 Q (PF2) 

ESC 0 R (PF3) 

ESC O S (PF4) 



3.2 CONTROL SEQUENCES FROM MPAD TO TERMINAL 

ESC = Set terminal in keypad application mode 

ESC 7 Save cursor 

ESC 8 Restore cursor • 

ESC [ 7 m Set reverse video 

ESC [ 0 ra All video attributes off 

ESC [ 5 i Enter printer controller mode 

ESC [ 4 i Exit printer controller mode 

ESC [ 0 k Erase line after cursor 

ESC E Next line 

ESC [ 20 h Set new line mode 

ESC [ x;y H Move cursor to line x and column y 

ESC [ ? 1 (=one) h Set cursor key mode 

ESC [2 J Erase all of the display 



A33JSI5M 
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4 HOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to- 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4, 5 

Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

Hl-03 ' General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information - • 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 



CCITT recommendations series V, 
books) V.24 and V.28 



ANSI X3.41 1974 
ANSI X3.64 1979 



1984 Edition {Red 
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This document specifies general requirements for fixed 
terminals, connected to the MOBITEX network. 
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1 GENERAL 



A fixed terminal is connected with a line interface for 
packet switching and line connection for line connection 
traffic (primarily speech). If the fixed terminal is 
connected to the mains, there are certain requirements for 
electrical safety. 



2 ELECTRICAL SAFETY 

For information about electrical safety requirements, 
please refer to Rl-06. 



3 SPECIFICATION OF LINE CONNECTION 

A fixed terminal should permit line connection traffic as 
a comolement to message traffic. For this to be possible, 
it is" necessary to have a real time connection between 
terminal and network in addition to the message traffic 
interface. A connection of this type can be used for 
transmitting speech for example. 

For information about line connection requireraements, 
please refer to Rl-06. 

TYPE OF CONNECTION: 4 wire speech connection with 

one speech direction per line 
pair. 

CONNECTION: ISO DIS 8877 plug" of European or 

D.S. type. 

FREQUENCY RANGE: 300 - 3400 Hz 

RECEIVER LEVEL DIRECTION -15 30 dBm 

SENDER LEVEL DIRECTION "10 23 dBm 

SIGNAL/NOISE RATION REC./SEND. : Greater than 40 dB 
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4 MOB I TEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with- the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 . HOBITEX System description 

Rl-03 . General description of terminals 

Rl-04 Terminology 

Rl-05 ., References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equinraent, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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EXPLANATION AND MODIFICATIONS 

This chapter has been newly added. It is an addendum providing a preliminary 
specification of additional requirements for portable terminals designed for 
operation on the Mobitex network. The primary motivation for this addendum is 
the need to provide a low power operating mode for portable units, to extend 
the operating time of their self-contained batteries. Because enhancements have 
been made to network signalling protocols over the air interface, these 
additional requirements will have some effect on the operation of mobile units 
as well. A careful review of this chapter is therefore required of all terminal 
designers and manufacturers. 

Since the addendum document was printed, several changes have been made 
to the protocol. They wfll be included in a future revision of the ERfTEL - 
provided specification. These changes, which should be . applied to the MTS 
15.1 document immediately following, are detailed below so that this very 
important new information can be brought to the attention of interested parties 
in a timely manner. 

1. Section 3.5, page 8: the first paragraph should be changed to read: 

If the terminal has lost consecutive <SVP6> signals over a period 
less than 60 seconds, it should remain in the operating state to 
synchronize again. If the terminal has not succeeded in synchronizing 
within 60 seconds, it should initiate the roaming procedure. 

Z Section 3.6, page 12: the two paragraphs under the heading "Evaluation of 
other base stations" should be changed to read: 

The evaluation of base stations on the CURRENT-SYSTEM-CHANNEL 
should be based on the average received signal strength over a time 
period indicated in <SVP6> (default value, 60 seconds). 

The integration time for evaluating base stations on other channels is 
indicated In <SVP6> (default value, 3 RSSI-PERIODS). . 

3. Section 3.8.1, page 13: the second paragraph under the heading "UP LINK 
TRAFFIC" should be changed to read: 

For uplink traffic the terminal should enter the OPERATING state and 
then follow the normal access rules, Le., wait for a <FRI> signal and 
then choose a random slot in which to transm'rt. 

4. Section 3.10, page 17: This section deals with voice operation and may be 
disregarded. 
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5. Section 4, pages 25 and 28: Note that the <SVP5> and <SVP6> may 
contain up to 186 MANs each. A parameter will be added in the currently 
unused portion of the primary block of <SVP5> and <SVP6> to indicate 
the number of MANs in the mail list or traffic list, respectively. 

6. Section 4, pages 28 and 29: parameters will be added in the currently 
unused portion of the primary block of <SVP6> to indicate signal strength 
evaluation times for the CURRENT-SYSTEM-CHANNEL (default 60 seconds) 
and other channels (default 3 RSSI-PERIODS), (See item 2. above). 

7. Section 4, page 29: the entry for TRANSACTION-TIME" should be changes 
to read: 

States the time the terminal should stay in OPERATING state after (1) 
reception of a message from the network, and (2) transmission of a 
message to the network. (0-255) X 250 ms. Default value: 40 (10 
seconds). TRANSACTION-TIME starts after transmitting or recieving an 
<ACK>, respectively. 

8. Section 6, pages 35 and 36: the following three items listed as design 
recommendations have been changed to design requirements, and their 
functionality must be included in portable units: 

Automatic change to mobile terminal operation (page 35) 

User notification of 'lost contact 1 (page 36) 

Display RSSI to user before transmitting (page 36) 

The remaining three items - manual selection of operating mode, prevention 
from automatic quick channel monitoring, and manual initiation of channel 
monitoring - continue to be design recommendations. 



ADDITIONAL INFORMATION 

In the "INFO" MPAK (See MTS 09A2, pages 107 and 108), portable terminals 
will be defined as terminal type number 4.The INFO MPAK will also now include 
a parameter indicating the operating mode of the portable unit (mode = mobile 
terminal mode; mode 1 = battery saving mode). 

In the MASC interface (see MTS 19A.2), new commands will be added to 
accommodate portable terminals. Details will be provided later. 
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PROTOCOL FOR HAND-HELD PORTABLE 
TERMINALS FOR USE IN MOBITEX 



PRELIMINARY SPECIFICATION. 



ABSTRACT 



This document specifies additional requirements for hand- 
held portable terminals to be connected to the MOBITEX 
system. 

An interface for hand-held portable terminals, where power 
conservation is one prime objective, is defined. 

This document should be considered as an ADDENDUM to the 
MOBITEX Terminal Specification (MTS) for 8 kbps mobile 
terminals, LZBA 703 1001, R1A. 



A 232 5X33/3 
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1 INTRODUCTION 

This document specifies additional requirements for hand- 
held portable terminals to be connected to the MOB I TEX 
system. 

It should be considered as an ADDENDUM to the complete 
MOBITEX Terminal Specification for 8 kbps mobile 
terminals, LZBA 703 1001, R1A. 

If certain requirements are made for hand-held portables 
these are made in this document. It could either be new 
additional requirements or new requirements that replaces 
ones that are made in the specification for ordinary 
mobile terminals. 



2 GENERAL DESCRIPTION 

A hand-held_j?or table terminal is basically a mobile 
terminal and should therefore conform to the requirements 
for mobile terminals, but with the additional ability to 
go into low power drain operating mode and wakeup when 
required to receive messages from the network. 

When the hand-held has received its messages it goes 
asleep again. 

One limitation for portables in this mode is that messages 
to these terminals may be delayed during the time when the 
portable is asleep. 

Whenever a hand-held wants to send a message it 
immediately wakes up, waits for a free-signal and sends 
the message. The terminal then stays awake for a period of 
time in order to be be able to receive a quick message 
response. 

The roaming procedure is essentially the same as for 
ordinary mobiles, but is controlled from separate sweep- 
parameters for hand-held terminals. The hand-held 
terminals performs the base evaluation during its awake 
time. 
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This protocol for hand-held terminals defines four new 
subtypes of the sweep-signal, <SVP>. These subtypes are 
numbered from 3 to 6.. 



<SVP3> - Sweep frame of subtype 3 

Includes roaming parameters and channel list used by 
hand-held terminals. <SVP3> corresponds to <SVP1> 
used by mobile terminals. 



<SVP4> - Sweep frame of subtype 4 

Contains channel numbers and channel types used in 
fleet division procedure. <SVP4> corresponds to 
<SVP2> used by mobile terminals. 



<SVP5> - Sweep frame of subtype 5 



Contains a list of— terminal MAN that has messages 
stored in the network mailbox. 



<SVP6> - Sweep frame of subtype 6 

Contains a list of terminal MAN or Group MAN that 
will have traffic from the network during this sweep 
cycle. 

This sweep frame also contains timing parameters for 
synchronization and message transfer. 
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3 OPERATING PRINCIPLES 



3.1 START OP PROCEDURE 

When the portable is powered up for the first time and/or 
when it has lost synchronization with the network or lost 
important information/parameters, it should consider 
itself to be in normal mobile terminal mode and act 
according to that. 

When the hand-held has found a system channel on a base 
station to use, received the relevant parameters from the 
base and synchronized to it, the terminal should send MPAK 
ROAM or ACTIVE according to the roaming procedure. 

The hand-held always has the possibility to go to normal 
mobile terminal mode , e.g. when the terminal is put in a 
power charger or for a major data transaction session when 
you want to be active all the time. In order to inform the 
network of this change of mode, the hand-held sends a new 
MPAK called MODE. " 



3.2 STATES 

There are two different states that a hand-held terminal 
could enter when it is in the low power drain mode; 
STANDBY state or OPERATING state. 

The STANDBY state should be considered as a 'sleeping' 
mode where only time keeping functions for synchronizing 
the terminal to the base station are in operation. 

In the OPERATING state the terminal should be considered 
as fully operational. 
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3.3 TRAFFIC LIST 

The hand-held terminal is notified in a TRAFFIC LIST that 
traffic will sent to the terminal. 

The TRAFFIC LIST contains the TERMINAL-MAN or the GROUP- 
MAN of those terminals that should remain in the OPERATING 
state in order to be available for the down-link traffic 
from network. 

The TRAFFIC LIST is part of a new <SVP>-frame of SUBTYPE 
6, denoted <SVP6>-f rame. 

Terminals not included in the TRAFFIC LIST may directly go 
back to STANDBY, state in order to save battery. ' 



3.4 MAIL LIST 

Messages not acknowledged by the terminal may be stored in 
the network mailbox according to the conditions describes 
•in Rl-09, 8kbps MTS. 

In order to inform terminals that have messages in the 
network mailbox, the MAIL LIST is introduced. 

The MAIL LIST contains a list of. those terminal MAN having 
messages in the mailbox. The MAIL LIST is within the 
<SVP>-frame of subtype 5, denoted <SVP5>. 
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3.5 SYNCHRONIZATION TO THE NETWORK 

Hand-held terminals using the this battery saving protocol 
cyclically goes from the STANDBY state to the OPERATING 
state. 

The terminal must be synchronized to the <SVP6> (TRAFFIC 
LIST) sent from the network. The <SVP6> frame is sent 
periodically from the network on the system channels where 
hand-held terminals can operate and use the battery saving 
protocol. 

The <SVP6> also contains the parameter TIME-TO-NEXT 
indicating the remaining period of time from this <SVP6> 
to the next time the terminal should enter the OPERATING 
state. 

TIME-TO-NEXT = time from first bit (bit 1) in the 

framehead of the received <SVP6> to the 
next time the terminal should enter the . 
OPERATING state. 

The <SVP6> also contains the parameter CYCLE-TIME which is 
the nominal cycle time between the start of two operating . 
states. 

The length of the CYCLE-TIME parameter is a compromise 
between response-time requirements and power consumption 
requirements of the terminal. 

Normally the terminal uses the TIME-TO-NEXT parameter in 
the <SVP6> to synchronize to the next time to enter the 
OPERATING state. If one or more of the <SVP6> frames are 
lost, the terminal should use the CYCLE-TIME parameter in 
order not to lose synchronization. 

Once the terminal has entered the OPERATING state it 
remains in this state until it receives an <SVP6> frame 
with a TRAFFIC LIST where the terminal is not included. 
The <SVP6> is terminating the transmission of the sweep 
frames . 

If the network is going to send other sweep frames when 
the terminals are In the OPERATING state, they will be 
sent prior the <SVP6> frame. 

If none of the <SVP3> to <SVP6> has been received within 2 
seconds from the transition to the OPERATING state, the 
terminal could return to STANDBY. 

After the reception of every <SVP3> to <SVP5> the terminal 
stays in OPERATING state for another 2 seconds or till it 
receives an <SVP6>. 
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If the hand-held consider itself as having lost 
synchronization to che network, e.g. lost of a number o? 
consecutive <SVP6>, it should stay in OPERATING sfcat* to 
synchronize again. 

Example 1 : 

Terminal uses TIME-TO-NEXT for synchronizing. 

Base <SVP6> <SVP6> 

I I TIME -TO— NEXT 1 | 



CYCLE-TIME 



Terminal — 'opr^ STB — 'opr'-STB 

OPR = terminal in OPERATING state 
— STB._= terminal in STANDBY state 

Example 2 : 

Terminal is using the CYCLE-TIME when <SVP6> is lost to 
keep synchronization. 



HlIME-TO-NEXT 
— CYCLE-TIME - 




OPR STB~ 



OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 



Example 3: 

Multiple sweep frame could be sent during the OP ERAtt re- 
state. 



<SVP3>,<SVP4>,<SVP5>,<SVPS> 

II!! 



'TIME-TO— NEXT 
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Terminal does not receive any sweep frame within 2 seconds 
from the start of the OPERATING state and returns to 
STANDBY. 



—CYCLE-TIME - 



Example 5: 

The terminal receives a <SV?3> but the <SVP6> is not 
received so the OPERATING state is terminated by the 2 
second timeout. 

The timeout-is counted from the reception of the <SVP3> 
frame. 

Base <SVP3> 
I 
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3 . 6 ROAMING 






The roaming procedure for hand-held terminals follows 
basically the roaming procedure for mobile terminals 
described in Rl-16. 




Since a hand-held terminal is most of the time in the 
STANDBY state, the normal monitoring of the roaming 
procedure must be carried out during the time when the 
terminal is in the OPERATING state. During the OPERATING 
state the terminal measures the averaged received signal 
strength and calculates a roaming value. 




The system parameters controlling the roaming procedure 
for hand-held portables are defined in the <SVP3>-f rarae. 
This gives the possibility to have different parameters 
for mobile terminals (defined in the <SVP1> frame ) and 
for hand-held portables. 




In order to control the performance of the terminals 
roaming procedure, different roaming parameters can be set 
in the <SVP3>-f rame from the network. Here are some 
examples described and the impacts on the terminals 
performance. 




Example 1: 






If SCAN TIME = 0 the terminal only monitors the 
CORRENT_SYSTEM_CHANNEL during the OPERATING state. 




At evaluation, if the roaming value < BAD_BASE the 
terminal goes to the 'quick channel monitoring' procedure 
since no other channels has been detected. 




Base : <SVP6> 
i 


<SVP6> 
1 




Term : "Wr 1 STB 'oPR 1 STB 




m = monitor CURRENT SYSTEM CHANNEL 
OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 




The other sweep frames are not shown in this figure but 
are coming before the <SVP6> frame if they are sent out. 
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Example 2 : 



If SCANJTIME = 1 ... 255, the terminal monitors other 
channels according to the channel list information the 
mobile has derived in the <SVP3> or from the default list. 

The start of the scan period is only critical in that 
sense that the terminal must not leave the system channel 
and monitor another channel when it should be in OPERATING 
state. 

The terminal should not leave CURR£NT_SYSTEM_CHANNEL and 
monitor other channels during the sweeD cycle if it is 
addressed in the TRAFFIC LIST. 




m = monitor CORRENT_SYSTEM_CHANNEL 
s = scan other system channels 
r = RSSI_PERIOD 
OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 

Please see the chapter ROAMING in Rl-16 for further 
information. 
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Criteria foe Leaving base 






The same criteria for leaving the CURRENT BASE applies for 
a hand-held terminal as the mobile terminal but with the 
parameters in the <SVP3> frame. The fifth criteria (item 
-5-) is not valid for hand-held terminals. 




Please see the chapter ROAMING in Rl-16 for further 
information. 




Evaluation of other base stations : 




The evaluation of base stations on the CURRENT S¥ STEM- 
CHANNEL , should be based on the averaged received sianal . 
strength from at least 60 seconds or some other suitable 
integration time. 




When evaluating other channels than the 
- CURRENT_S¥.STEM CHANNEL-,- -roaming- values from at least three • 
(3) RSSI PERIODS should be averaged. 




Quick channel monitoring : 






In quick channel monitoring when the SCAN TIME = 0 and 
when the terminal has found a channel with a 
roaming value > GOOD_BASE, the terminal should remain on 
the channel for at least 5 seconds during the measuring of 
received signal strength. Please refer to 'quick channel 
monitoring' part (item -4-}. of the ROAMING chaDter in 




At Power On 






When the hand-held terminal is switched on it should use 
the stored CURRENT_SYSTEM_CHANNEL and the CURRENT BASE. 




If there is no CURRENT BASE stored the terminal directly 
starts the quick channel monitoring procedure using the" 
default list of system channels. When a CURRENT SYSTEM- 
CHANNEL and a CURRENT BASE has been found and the MPAK 
ROAM has been sent to the network, the terminal 
synchronizes to the <SVP6>-f rames . 


H«p.-,»! 
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3.7 FLEET DIVISION OF HAND-HELD PORTABLES 

In order to assign a certain system channel (and/or access 
channel) to hand-held terminals or parts of the fleet of 
the hand-held terminals a <SVP>-f rame of SUBTYPE 4 is 
introduced, denoted <SVP4>-f rame . The <SVP4>-f rame should 
be interpreted in same way as the <SVP2>-frame for mobile 
terminals, described in 8kbps MTS section Rl-16. 



3,8 MESSAGE TRANSACTIONS 
3.8.1 OP LINK TRAFFIC 



The access requirements for up-link traffic from a hand- 
held terminal are basically the same as for a mobile 
terminal. 

A hand-held terminal that is going to transmit a message 
to the network enters the OPERATING state directly and 
waits for a valid <FRI>-frame from the network accordinq 
to the 8kbps MTS. 

When the terminal makes an access request for data using 
the <ABD>-frame , the terminal should follow the 8kbps MTS 
dialogues and remain in OPERATING state till the <MRM>- 
frame is transferred successfully or when the dialogue 
terminates for any reason. 



After the message is successfully transferred to the 
network the hand-held terminal remains in OPERATING state 
for TRANSACTION-TIME, defined in <SVP6>, before it goes 
back to STANDBY state. This gives a possibility for 
transferring an answer back to the hand-held without any 
delays caused by the waiting time to the next TRAFFIC LIST 
transmission. This function could be considered as if a 
'logical down-link channel' has been opened to the 
terminal for TRANSACTION-TIME. 
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3.8.2 DOWN LINK TRAFFIC 

Hand-held terminals having down-link traffic is addressed 
in the TRAFFIC LIST. 

When the hand-held terminal receives a TRAFFIC LIST that 
contains one of its terminal addresses (TERMINAL MAN or 
GROUP MAN) it stays in OPERATING state and awaits one 
message. 

When the message is successfully received the terminal 
stays in OPERATING state for TRANSACT ION-TIME in order to 
be able to receive more down-link messages cominq from the 
network. The parameter TRANSACTION-TIME is included in the 
<SVP6>-frame, and is the same as for up-link traffic. 

If no message has been received within the TRANSACTION- 
TIME elapsed from the reception of the last message, the 
terminal can leave OPERATING state. 

The terminal can also leave OPERATING state when it . . 
receives a TRAFFIC LIST without any of the terminal 
addressees. 

When a hand-held terminal is ordered to another channel 
for down-link data transmission, <BECD> frame from network, 
the hand-held terminal should remain in the OPERATING 
state until the data transmission dialogue is completed 
according to the 8kbps MTS. 

Terminals not included in the TRAFFIC LIST may directly go 
to STANDBY state in order to save battery. 



Example 1: 

Terminal is not in traffic list 
Base : <SVP6> <SVP6> 



Term 




STB"" 




"STB" 



OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 
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Terminal is in traffic list of <SVP6> and the 
network has one <MRM> to transmit. 



<SVP6> <MRM> 



• tt ^ 



<SVP6> 
I 



TT = TRANSACTION— TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 

Example 3: 

Terminal is in traffic list of <SVP6> and the 
network transmits multiple <MRM> within the sweep 
cycle. e ■ 

Base : <SVP6> <MRM> <MRH> <SVP6> 



TT = TRANSACTION-TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 
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3 . 9 ACTIVATION / INACTIVATION 

The hand-held terminal use of the ACTIVE/INACTIVE packet 
has been modified to better suit their environment and 
application. 

Hand-held portables used in-doors will lose contact with 
the network. much more frequently then mobile terminals. 
Hand-held terminals should therefore not send ACTIVE due 
to "lost contact' according to the roaming procedure since 
this will cause considerable system signalling overhead. 

Hand-held terminals should send INACTIVE / ACTIVE when 
switched-of f and switched-on respectively. 

When a hand-held terminal is addressed in the MAIL LIST it 
has the possibility to empty the mailbox by sending an 
ACTIVE packet. 



Terminal is in mail list of <SVP5> and the network 
has one or more <MRM> placed in mailbox. 

Base : <SVP5> <ACK> <MRM2> <SVP6> 

III I 
Term : <MRM1> <ACK> 

I TT H— TT H 

' OPR '"STB 'oPR^ — STB - 



TT = TRANSACTION-TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 

MRM1 = MPAK ACTIVE 

MRM2 = any MPAK from mailbox 
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3.10 LINE CONNECTION 

Call set-up and disconnection procedures for line 
connection to a hand-held terminal follows the 
requirements in the 8kbps MTS. 

When a hand-held terminal is called from the network for a 
line connection, the terminal is addressed in the TRAFFIC 
LIST with the TERMINAL MAN or one of the GROUP MAN. The 
terminal remains in the OPERATING state and follows the 
normal procedure for call set-up described in the 8kbps 
MTS. The terminal can leave the OPERATING state when the 
call is disconnected, according to the dialogues in the 
8kbps MTS. 



When a hand-held terminal initiates a call set-up for a 
line connection, the terminal enters OPERATING state 
before sending the line connection request, and stays in 
this state until the call is disconnected, according to 
the 8kbps MTS. 
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4 ADDITIONAL FRAMES - DATA LINK LAYER 


FRAME TYPE <SVP>, 


Sweep signal 


APPLICATION The sweep signal is a periodically 

recurring signal from BASE. An <SVP> is 
transmitted by. BASE for two reasons: 


1) 




<SVP> marks the start of a sweep 
cycle. 


2) 




<SVP> contains system 
parameters. 


<SVP> has 2 different subtypes for mobile 
terminals and 4 subtypes for hand-held 
portable terminals : 


SUBTYPE 1 




states the values of system 
parameters for mobile terminals 


2 




scates the frequency of • 
different channel types for 
mobile terminals 


3 




subtype only for hand-held 
terminals using the battery 
saving protocol described in 
this document. This subtype 
contains the system parameters 
for the hand-held terminals. 


4 




states the frequency of 
different channel types for 
hand-held terminals. 


5 




includes the MAIL LIST for 
terminals (may be used both by 
mobile terminals and hand-held 
terminals) 


6 




includes the TRAFFIC LIST and 
the timing parameters for hand- 
held terminals 


Note 1: <SVP> of subtype 1 and 2 are not described in this 
Addendum. Please refer to 8kbps MTS Rl-16. 


Note 2: For <SVP5> 
correctly 
the whole 


and <SVP6>, the hand-held should use 
received following blocks, even though 
frame may not be correct. 



Exhibit 2, p. 529 



I9~ 







"\056 


1 1 
- A 296 6084 Ue 






C 9 0-0 5 - 1 1 ' "E A3 | MTS15 . i 


<SVP> , 


SUBTYPE 3 


- states the values of system 
parameters for hand-held 
terminals. 


PRIMARY BLOCK 












01 02 03 
i i 


22 


23 24 


25 26 27 


28 29 30 31 32 






MOB 


0 0 0 


0 1111 






33 34 35 
1 I 


36 37 38 


39 40 


41 42 43 


44 45 46 47 48 
i i i i 






PRIO 


MASK 


BLOCK 






49 50 .51 


52 53 54 
i i i 


55 56 
i 


57 58 59 


60 61 62 63 64 
i i i i 






SVPTYP 


TXPOW 






65 66 67 


68 69 70 
i i t 


71 72 


73 74 75 

i i 


76 77 78 79 80 
i i i i 






RSSI_PROC 


RSSI_PERIOD 






81 82 83 
1 1 


84 85 86 
1 1 J. 


87 88 


89 90 91 


92 93 94 95 96 
till 






0 0 0 


0 0 0 


0 0 


MAX_REP 






97 




104 


105 


112 






BASEST 


SCANJIIME 






113 

l 1 i 


1 1 1 


120 
i 


121 


128 






BAD_BASE 


GOOD_BASE 






129 




136 


137 


144 






BETTER_BASE 


0 0 0 


0 0 0 0 0 






145 








160 






PARITY 
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SVPTYP 


States the <SVP> subtype, value 
00000011 in this case"." 




TXPOW 


States the decrease in output 
power (0-255 dB below nominal, 
level) to be used by the hand- 
held terminal. The default value 
of 0 is used until this signal 
is received. 




RSSI_PROC 


States the method of the signal 
strength measurement: 

0 = FRAME 

1 = CONTINUOUS 

The default value is FRAME. 




RSSI_PERIOD 


Time used by the roaming 
algorithm (0-255 *20 ms) . 
Default value: 148 (2 960 ms ) . 




MAX_REP 


States the value of the .variable 
Max_r ep . 




BASEST 


States status of base station. 




SCANJTIME 


States the length of a period 
(0-255 *100 ms) when the hand- 
held terminal scans other system 
channels . 

Default value: 30 (3 seconds). 




BAD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 




GOOD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 




BETTER_BASE 


Used- by the roaming algorithm, 
u z jd ud. uerauxc vaxue: xu. 
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If any, they contain a list of 
system channels to be used in 
base station monitoring. A frame 
with a list containing new 
system channels completely 
overrides the previous frame. 
The channel list has the 
following format (as described 
in the MAIN DOCUMENT) : 



01 02 03 04 05 06 07 08 


09 10 11 12 13 14 15 16 

! 1 1 1 1 ! ! 


number of channels 


0 0 0 0 0.0 0 0 


17 32 


33 48 


channel $1 - UPFREQ 


channel #1- - DOFREQ 


49 - 64 
> i ii 


65 . 80 
ii ii 


channel #2 - UPFREQ 


channel #2 - DOFREQ 


81 96 
1 1 1 I I 


97 112 
1 I i i 


channel #3 - UPFREQ 


channel #3 - DOFREQ 


113 128 


129 144 

! ! - I I 


channel if 4 - UPFREQ 


channel #4 - DOFREQ 


145 leo 

1 1 1 ! 1 1 ! 1 1__ 11111,1 



PARITY 



The number of following blocks depends on the size of the 
list. The maximum number of channels in the list is stated 
in reference Rl-06. 

Continues with following block #2 on the nexc page. 



FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 
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FOLLOWING BLOCK §2 



channel #5 - 


UPFREQ 


channel #5 - 


DOFHEQ 


33 


48 

1 1 


49 

i i 


64 

1 1 


channel #6 - 


UPFREQ 


channel #6 - 


DOFREQ 


129 


144 
i I 


145 


160 


channel #9 - 


UPFREQ 


PARITY 



FOLLOWING BLOCK #3 



II II 
channel #9 - DOFREQ 


channel #10 - UPFREQ 


33 48 
I 1 1 i 


49 64 


channel #10 - DOFREQ 


channel #11 - UPFREQ 
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<SVP>, SUBTYPE 4 
PRIMARY BLOCK 



- states the frequency of 
different channel types for 
hand-held terminals. 



01 02 03 22 23 24 
1 1 1 !... .lit 


25 26 27 28 29 30 31 32 
1 1 1-.- Ill i 


MOB 


00001111 


33 34 35 36 37 38 39 40 
1 1 ! i_ _J. 1 1 1 


41 42 43 44 45 46 47 48 
1 1 I I I i I 


PRIO MASK 


BLOCK 


49 50 51 52 53 54 55 56 
1 1 1... Illlt 


57 58 59 60 61 62 63 64 
L...1 .1 1 1,1 1 


SVPTYP 


CHATYP 


65 66 67 68 69 70 71 72 73 7.4 75 76 77 78- 7-9-80 
... i i i i i i i i i i i i i i i 


UPFREQ 


81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 ! 


DOFREQ 



97 98 99 100 



0 0 0 0 0 0 



0 0 0 0 0 0 



_1 I I J !_ 
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States the <SVP> subtype, value 00000100 
in this case. 

States the type of channel: 
Value : 

1 Local system channel opened 

2 Not used (ignore that order) 

3 Local system channel closed 
(return to previous system 
channel) 

4 Access channel opened 

5 Access channel closed 

Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number for down frequency, i.e. 
the frequency on which BASE transmits. 



FOLLOWING BLOCK ■■ No following blocks in this type 

• of frame. 
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<SVP>, SUBTYPE 
PRIMARY BLOCK 


5 






- contains a list of terminal 
MAN that has messages stored 
in the network mailbox 




01 02 03 
i i 




22 


23 24 


25 26 27 


28 29 


30 31 32 
1 ' 






MOB 


0 0 0 


0 1 


111 






33 34 35 


36 37 
i 


38 


39 40 


41 42 43 
i i 


44 45 


46 47 48 






PRIO 


MASK 


BLOCK 






49 50 51 


52 S3 
i 


54 


55 56 


57 58 59 


60 61 


62 63 64 






SVPTYP 


0 0 0 


0 0 


0 0 0 






6-5 66 67 


68 69 


70 


71 72 


73 74 75 
1 1 I 


76 77 


78 79 80 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






81 82 83 


84 85 


86 


87 88 
i 


89 90 91 

....1 1 I 


92 93 
.._ 1 


94 95 96 
1 ' . 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






97 




1 




104 


105 


t 1 


112 
I 1 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






113 

L. 1 ' 


■ 1 ! 






120 
i 


121 

1 1 L 


1 1 


128 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






129 

i i i 








136 
1 


137 

i i i 


1 1 


144 






0 0 0 


0 0 


0 




0 0 


0 0 0 


0 0 


0 0 0 






145 

i i i 


1 1 






1 1 






160 






PARITY 




SVPTYP 








States the <SVP> subtype, value 
00000101 in this case. 
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Containing a list of terminal 
MAN that has been stored in the 
network mailbox. 



The number of following blocks deoends on the size of the 
list. 

Continues with following block #2 on the next page. 
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etc. 
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<SVP>, SUBTYPE 6 



PRIMARY BLOCK 

01 02 03 



• contains the timing parameters 
used in synchronization and 
message transactions 



0 1111 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ■ 



49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 



CYCLE-TIME 



TIME— TO— NEXT 



TRANSACTION-TIME 



000 0 000000000000 



0000000000000000 



0000000000000000 



000 0 000000000000 



_! 1 ! ! ! !_ 
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CYCLE-TIME 



TIME-TO-NEXT 



TRANSACTION-TIME 



States the <SVP> subtype, value 
00000110 in this case. 

States the cycle time between 
two OPERATING states (0-255 x 
250 ms). 

States the time to the next 
<SVP6> frame (0-255 x 250 ms). 

States the time the terminal 
should stay in OPERATING state 
after 1) reception of a message 
from the network and 2) 
transmission of a message to the 
network (0-255 x 250 ms). 
Default value: 80 (20 seconds. 
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FOLLOWING BLOCKS 



FOLLOWING BLOCK SI 



Containing a lisb of terminal 
MAN or group MAN that are going 
have down-link traffic during 
this sweep cycle. 



3 



The number of followina blocks depends on the size of the 
list- 
Continues with following block #2 on the next page. 
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FOLLOWING 3 LOCK #2 

01 24 



MAN 7 1 


25 

1 1 


MAN 8 


48 


49 

i i 




72 


MAN 9 J 


73 

... I I .. . 




96 




MAN 10 




97 




120 


MAN 11 | 


121 




144 


MAN 12 | 


145 

1 1 




160 




PARITY 





etc. 
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5 ADDITIONAL MPAK - NETWORK LAYER 



A new MPAK is included for terminals using the battery 
saving protocol. The MPAK is used to inform, the network 
that the terminal has changed from battery saving mode to 
operate as a normal mobile terminal and vice versa. 

The new MPAK is within the packet class DTESERV (3) and 
has the packet type = 24. 



MODE (mode information) : 

Designated sender; 

The hand-held portable terminal. 

Designated addressee: 
The network. 

Raised flags: 
No raised flags. 

Criteria for generating the packet: 

When hand-held portable terminal changes from the battery 
saving protocol to operate as a mobile terminal this 
packet is used to inform the network. 

The same packet is sent to the network, but with a 
different mode identifier, when the terminal enters the 
battery saving protocol from being operating as a mobile 
terminal. 
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The network's normal action when receiving the packet: 

The network registers how the terminal operates, and 
forwards down-link traffic to the terminal in accordance 
to this. If terminal is using the battery saving protocol, 
the terminal is addressed in the TRAFFIC LIST. 

If the terminal is operating as a mobile terminal the 
network sends traffic immediately to the terminal. 



The terminal's normal action when receiving the packet: 
The terminal does not normally receives this packet. 



Length of the packet: 
9 octets. 
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MODE as generated by the terminal : 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the terminal 



addressee : the Mobitex Network 



0 0 0 0 



110 0 0 



TYPE DEPENDENT COMPONENT 
octet 9 : 



mode identifier 



mode identifier : 

0 = mobile terminal operation 

1 = battery saving protocol operation 
2-255 = reserved 
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6 DESIGN RECOMMENDATIONS 



Manual selection of Battery saving operating mode - Mobile 
terminal operating mode 



When the hand-held terminal is mounted into a battery 
charger in a car for example, it is recommended that 
terminal leaves the battery saving protocol operation and 
operates as mobile terminal. In chat case the user or the 
terminal itself initiates the transmission of the MPAK 
MODE to the network. The MPAK MODE will then identify the 
operating mode the terminal uses. 



Automatic change to mobile terminal operation. 

If the terminal could not find any signalling required for 
the battery saving protocol operation (<SVP6>), but 
detects <SVP1> required for mobile terminal operation, the 
terminal could act as mobile terminal. The user should be 
informed of this so the terminal could be switched-of f . 

The MPAK MODE is sent to the network informing that the 
terminal has gone into mobile terminal operation. 



Prevention from automatic quick channel monitoring 

In order to prevent the automatic quick channel monitoring 
from continuously running or to prevent the terminal from 
repeated attempts to go into the quick channel monitoring, 
it is recommended that the user manually can switch the 
quick channel monitoring function off. 

It is also recommended that the terminal has some kind of 
watchdog function implemented, limiting the operating time 
in quick channel monitoring mode. 



Manual initiation of quick channel monitoring 



If the hand-held terminal is implemented without automatic 
quick channel monitoring functions it is recommended that 
this function can be manually initiated. 
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User notification o£ 'lost contact' 



When the terminal loses contact with network, according to 
roaming procedure, and goes into quick scan monitoring the 
operator of terminal should be notified. It is also 
suitable if the received signal strength indication (RSSI) 
is displayed to the user so positioning of the terminal 
could be facilitated. 



RSSI when transmitting 

It is recommended to display the received signal strength 
to the user especially when the terminal is going to 
transmit, so the user can move the terminal to a good 
location. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the Dage(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 21 
Rl-09, 6 

Rl-16, 10, 11, 12, 13, 18 



Below are the reference designations listed. 

Reference Section 

R1 ~ 01 Arrangement of the documents 

Rl-0 2 MOBITEX System description 

R1- 03 • General description of terminals 

Rl-04 Terminology 

R 1-QS References 

R1 ~ 06 Network operator information 

Rl-08 Application layer 

R l-09 Network layer 

R1-11 Interface requirements, fixed terminals 

R1 ~ 12 Other requirements, fixed terminals 

R1 ~ 16 Link layer, mobile terminals 

R1 ~ 17 Physical layer, mobile terminals 

R1 ~ 18 Radio equipment, mobile terminals 

Other interfaces, mobile terminals 

R1 ~ 20 Other requirements, mobile terminals 
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MOBITEX 

Data Link Layer, Mobile Terminal 
8/16 kbps 



ABSTRACT 

This document specifies the data link layer for terminals 
connected to the MOBITEX network. 

The mobile terminal's Data Link Layer together with the 
Physical Layer form a radio protocol for communication 
between mobile- stations (MOB) and a base radio station 
(BASE) . 

The interchange of information between BASE and MOB is in 
the form of frames. There are 21 different types of 
frames. 

A number of different access strategies are used in the 
protocol to permit the handling of a large number of 
mobile terminals on a few trunked channels. The most 
important aspects are: 

Time slots 

Selective repetition 
Priority access 
Concurrent channels 
- Automatic roaming. 

To achieve high transmission reliability, the frames are 
divided into blocks where each block is coded. 



Htprod 
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The Link Layer of mobile terminals forms a link between 
the Network Layer and the physical radio channel with its 
special properties. It ensures a safe and efficient 
transmission path between the mobile terminal and the 
network, represented by the base stations. The Link Layer 
includes error correction facilities,, access algorithms, 
roaming algorithms, priority facilities etc. 
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2 INTERACTION WITH UPPER LAYERS 

The upper layers handle packets of information, MPAK . The 
following figure presents the general apperance of an MPAK 
(it is fully described in reference Rl-09). 



Type, status etc. 



Type-dependent 
component 



The Link- Layer transmits the MPAK in the form of 'a frame. 
The frame structure is defined in chapter FRAME STRUCTURE . 
The conversion .of a packet into a frame is described in 
APPENDIX A. 

If the Link Layer is unsuccessful in transferring an MPAK 
to the network, it is returned to the Network Layer, with 
this information. The Network Layer can then request a new 
attempt by sending the MPAK back to the Link Layer. 



AJS2JW3 
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3 . 1 PARTS OF THE FRAME 

The transmission of digital information over the radio 
channel is performed by transmitting frames. A frame 
• comprises a limited number of bits which are _ transmitted 
in an uninterrupted sequence. The frame consists of the 
following parts: 



sync pattern, base identity 



MOB address etc. 



Parity field . 



Information field 



Parity field 



Information field 



Parity field 



Frame head 
Primary block 



Following block #1 



Following block #n 



The frame head is described in detail in reference Rl-17. 
The information and parity fields of the following blocks 
are described in APPENDIX A, together with the primary 
block. 
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3.2 FRAME TYPES 



There are 21 different frame types: 

Name D esignation Transmitted by 
a BASE MOB 



l 


H frame 


<MRH> 


Yes 


Yes 


2 


Acknowledgement 


<ACK> 


Yes 


Yes 


3 


Negative acknowledgement 


<NAK> 


Yes 


Yes 


4 


Repetition request 


<REB> 


Yes 


Yes 


5 


Repetition reply 


<RES> 


Yes 


Yes 


6 


Access request, data 


<ABD> 


No 


Yes 


7 


Access request, speech 


<ABT> 


No 


Yes 


8 


Access request, emergency 


<ABL> 


No 


Yes 


9 


Access permission, data 
Access permission, speech 


<ATD> 


Yes 


No 


10 


<ATT> 


Yes 


No 


11 


Access permission, emergency 


<ATL> 


ires 


No 


12 


Change channel, data 


<BKD> 


Yes 


No 


13- 


•Change channel, speech 


<BKT> 


Yes 


No 


14 


Free signal 


<PRI> 


Yes 


No 


15 


Sweep' signal 


<SVP> 


Yes 


No 


16 


Silence order 


<TST> 


Yes 


No 


17 


Activity request 


<AKT> 


Yes 


NO 


18 


No access permission, speech 
Change base station, speech 
Wait for channel, speech 


<NAT> 


Yes 


NO 


19 


<BBT> 


Yes 


NO ■ 


20 


<VKT> 


Yes 


NO 


21 


Cancel access request, speech <AAT> • 


No 


Yes 
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The following pages give a brief description of each frame 
type. Refer to Appendix A "Frames" for a complete 
definition of frame types. 



An <MRM> is used to transfer packets (MPAKs). The 
packet formats are defined in reference Rl-09. 



Acknowledgement <ACK> 

An <ACK> acknowledges a correctly received frame. 

<ACK> indicates that all blocks in the frame have 
been correctly received. It includes the sequential 
number of the received frame. 

Negative acknowledgement <NAK> 

A <NAK> requests repetition of the entire <MRM>. 

<NAK> indicates that the primary block has been 
correctly received, but that the following blocks 
have been lost. It contains the sequential number of 
the received primary block. <NAK> results in a 
complete repetition of the lost <HRH>. 

Note that if the number of blocks in <MRM> was 3 or 
more, <REB> is used instead of <NAK>. 



Repetition request .. <REB> 

A <REB> requests repetition of erronous blocks in an 
<MRM> or <RES>. 

If it is found during reception that certain blocks 
in a frame are not correct, a request far these 
blocks to be repeated can be made by transmitting a 
<REB> . The request contains a bit map of the blocks 
to be repeated. This bit map refers to the original 
<MRM>, even during a sequence of repetitions. 

<REB> contains the sequential number of the received 
<MRH> and results in a <RES>. 

Note that if the number of blocks in <MRM> was 2 or 
less, <NAK> is used instead of <REB>. 



Exhibit 2, p. 



Caniel Mobitex- 



1990-02-26 A 



Repetition reply <RES> 

A <RES> is the reply to a <REB>. 

<RES> is a selective repetition of blocks from an 
<MRH>. The following blocks of the <RES> contain 
copies of blocks according to the bit map of the 
<REB>. <RES> contains the sequential number of the 
original <MRM>. 



6 Access request, data <ABD> 

An <ABD> is a request to transmit an <MRM>, 
containing "data" {defined in chapter "Addressing a 
mobile terminal"), whose length (number of blocks) 
exceeds the value of MAX_ACCESS. MAX_ACCESS is 
described in chapter "Time division"? 

If the length of the <MRM> exceeds MAX_ACCESS, 
access must be requested before the <MRM> may be 
sent. 

The <ABD> states the number of blocks in the 
corresponding <MRM>. 



7 Access request, speech <ABT> 

An <ABT> is a request to transmit an <MRM>, 
containing "speech" (defined in chapter "Addressing 
a mobile terminal"), containing a request for a line 
connection whose length (number of blocks) exceeds 
the value of MAX_SPEECH. MAX_SPEECH is described in 
chapter "Time division". 

If the length of an <MRM> with a connection request 
exceeds MAX_SPEECH, access must be requested before 
the <MRM> may be sent. 

The <ABT> states the number of blocks in the 
corresponding <HRH>. 
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Access request, emergency <ABL> 

An <ABL> is a request to transmit an <MRH> 
containing an "emergency" (defined in chapter 
"Addressing a mobile terminal"), whose length 
exceeds the value of MAX_ACCESS. HAX_ACCESS is 
described in chapter "Time division". 

If the length of the <MHM> exceeds MAX_ACCESS, 
access must be requested before the <MRM> may be 
sent. 

The <ABL> states the number of blocks in the 
corresponding <MHM>. 



Access permission, data <ATO> 

BASE replies with an <ATD> to an <ABD> from a MOB, 
when BASE is ready to accept an <MRM>. 

When permission is granted (<ATD> received), MOB is 
expected to transmit an <MHM> containing a data 
packet. 



Access permission, speech <ATT> 

BASE replies with an <ATT> to an <ABT> from a MOB, 
when BASE is ready to accept an <MRM>. 

When permission is granted (<ATT> received), MOB is 
expected to transmit an <MRM> containing a request 
for line connection. , 



Access permission, emergency <ATL> 

BASE replies with an <ATL> to an <ABL> from a MOB, 
when BASE is ready to accept an <MHM>. 

When permission is granted (<ATL> received), MOB is 
expected to transmit an <MRM> containing an 
emergency signal. 



Exhibit 2, p. 558 



Cantel Mobitex- 



1990-02-26 A 



Change channel, data <BKD> 

A <BKD> orders a MOB to another channel in order to 
transmit or receive an <:MRM>, data or emergency. 

Normally the terminal returns to the original 
channel when the <MHM> has been transmitted or 
received. If an error occurs on the assigned channel 
then MOB returns to the original channel after a 
timeout period stated in the <BKD>. 



13 Change channel, speech <BKT> 

A <BKT> orders a MOB to another channel in order to 
transmit or receive an <MRM> containing a request 
for line connection. 

Normally the terminal returns to the original 
— channel when the' line connection is over. If an 
error occurs on the assigned channel then MOB 
returns to the original channel after a timeout 
period stated in the <BKT> . 



14 Free signal <FRI> 

BASE transmits a <FRI> when it is ready to handle 
traffic from MOB. 

A free signal precedes a free cycle. A free cycle is 
a period of time .when all of, or parts of, the total 
fleet of mobile terminals are collectively permitted 
to transmit. 



15 Sweep signal <SVP> 

The sweep signal is a periodically recurring signal 
from BASE. An <SVP> is transmitted by BASE for two 
reasons: 

1 <SVP> marks the start of a sweep cycle. 

2 <SVP> contains system parameters, such as: 

' - time to next <SVP> 

- maximum number of repetitions' 

channel list 
local system channel 
access channel 
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Silence order <TST> 

Silence order is used by BASE to withdraw all access 
permissions during a free cycle. A MOB that is 
already transmitting may continue to do so, but for 
every other MOB the access permissions for all 
traffic types- (emergency, speech and data) are 
withdrawn. 

Note: Please also refer to the description of the 

silence signal in reference Rl-17. This signal 
has the same meaning as the <TST>-£rame but 
uses only the frame head and thus addresses 
ALL mobile terminals. 



Activity, request <AKT> 

An <AKT> is used by BASE to check whether a certain 
MOB is active. MOB replies with. an <ACK> to such _a 
frame. 



No access permission, speech <NAT> 

BASE replies with <NAT> to an <ABT> from a MOB when, 
■for some reason, a line connection cannot be set up 
(e.g. no channel is available). 



Change base station, speech <BBT> 
BASE will use <BBT> 

- as a response to an <ABT> when another base 
station is. to be used for the line connection 
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Wait for channel, speech <VKT> 

If no channel is immediately available, BASE may 
place MOB in .a queue of waiting calls and reply with 
a <VKT> to a received <ABT> . When a speech channel 
becomes available, BASE indicates this by 
transmitting a <BKT> to MOB- If there is no free 
channel within reasonable time, BASE ends the 
session by transmitting a <nat>. 



21 Cancel access request, speech <AAT> 

After having received a <VKT> from BASE, the mobile 
terminal may end the session by transmitting an 
<AAT>. 
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4 TRAFFIC HANDLING 

4.1 TRANSMISSION PRINCIPLES 

Transmission is carried out through the interchange of 
frames between MOB and BASE. Different types of trans- 
mission cases demand different behaviours by the units 
involved. Some of the problems considered in this chapter 
are: 



Access to the channel 



Keeping contact 
with the network 



Addressing 



Sequential numbering 



• describes how a small number 
of channels can handle 
concurrent traffic from a 
large number of subscriptions 
at the same time. 

■ describes how the mobile 
unit maintains its contact 
with the network (roaming). 

• describes how the addressing 
of base radio stations, 
terminals and subscriptions 
take place. 

■ describes how repeated 
presentations of repeated 
frames ace avoided. 
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4.2 ACCESS TO THE CHANN 


EL 


4.2.1 Time division 





A MOB, with traffic to send, is allowed to establish 
contact with the base radio station in special free 
cycles. These cycles are initiated by BASE by transmitting 
a <FRI>. 

This frame contains an indication of the length of the 
free cycle, including the following parameters: 

Slot_length States the length of each individual free 
slot. 

Pree_slots States the total number of free slots in 

the current free cycle. 

Rand_slots States the interval for" the random number 

generator in the MOB. 

Max_access States the maximum length of an <MRM>- 

frame, containing data or emergency, which 
can be sent without a preceding access 
request. 

Max_speech States the maximum length of a frame, 

containing a connection request, which can 
be sent without a preceding access 
request. 

In order to reduce the probability of a collision between 
traffic from several mobile units, the free cycle is sub- 
divided into slots. The length of these slots (Tl) are 
stated by the Slot length parameter. 



slot n+1 slot n+2 slot n+3 



By the aid of an internal clock, the mobile terminal is 
able to detect slot boundaries. The definition of how slot 
boundaries are calculated is found in reference Rl-17. 
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The following happens in the free slots. 

1 Traffic initiated before the start of the free cycle 
must be distributed at random. A random number 
generator selects a slot between 1 and Rand slots. 
Transmission begins at the start of the selected 
slot. 

2 Traffic initiated during che free cycle is sent at 
the beginning of the next slot. 

3 if the <HHM> to be sent is longer than MAX ACCESS or 
MAX_SPEECH, a request for access must be made. The 
transmission of this request is done according to 
rules 1 or 2 above. 



If the Data Link Layer is in the speech mode (ordered by 
the Network Layer), an <MRM> may be sent immediately. This 
is done independently of any free cycles. 



WJ9JS15W 
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4.2.2 Mobile fleet division 

The access permission in the free cycle can be given to 
parts (subsets) of. the mobile fleet according to the 
setting of corresponding fields in the free signal, <FRI>. 
This is used to reduce the number of access attempts in a 
free cycle. The following principles are used: 



Masked addressing 



Priority 



Traffic type, FFG 



The address and mask fields in <FRI> 
are used for. a binary division (1, 2, 
4, 8 etc) of the mobile fleet. 

Is used to give access only to mobile 
terminals above a stated priority 
level. 

Is used to give access only for stated 
traffic types (emergency, data or 
speech ) . 



In the <SVP> a channel (receiving and transmitting 
frequencies) and a channel type (local system or access 
channel) can be given. By using the addressing facilities 
in the <SVP> it is possible to assign a certain system 
and/or access channel to the whple mobile fleet or to 
parts of it. 

The local system channel is used in much the same way as 
any other system channel. It is not shared by surrounding 
base stations and may thus be used without interference 
from these. 

When assigned a local system channel, the mobile terminal 
monitors this channel until further notice or the roaming 
algorithm indicates that it is no longer usable. 

When assigned an access channel, the mobile terminal must 
use this channel when it. has an <MRM> to transmit. The 
access rules described above also apply to this channel. 
After the. <MHM> has been acknowledged the terminal returns 
to the previous (local) system channel. 
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The algorithm for selection of a suitable base is called 
roaming. It is designed to handle a nationwide system of 
base radio stations on different system channels, with 
either frequency or time division in their signalling. The 
algorithm includes two methods of channel monitoring: 
normal and quick. 

A mobile terminal measures the received signal strength 
from all base radio stations. To evaluate one base station 
the mobile terminal calculates its roaming value. The 
roaming value is defined as the average received signal 
strength. Please see reference Rl-17 for further 
information about how to measure received signal strength. 

After a <BKT> -or a <BKD> has been received, the monitoring 
is disabled. It is resumed after the connection/session is 
ended, and the same table of evaluations as before the 
connection is used. 

When the terminal is switched on, it uses the 
CURRENT_SYSTEM_CHANHEL and the CDRRENT_BASE until this 
base becomes unsuitable according to the roaming 
algorithm. If no CDRRENT_BASE has been stored, the 
terminal immediately starts the quick channel monitoring, 
using the default list of system channels. 



Lists of system channels 

The mobile terminal uses a list of system channels when it 
monitors the base radio stations or searches for a new 
base. It is either a permanent or a temporary default list 
(please refer to the chapter 'SYSTEM PARAMETERS TO BE 
STORED IH THE TERMINAL' and to reference Rl-06) or the 
current list (stated in the <SVP>-f rame) . 

The default list is used until a <SVP>-frame has been 
received. A <SVP>-frarae with a new list of system channels 
completely overrides the old current list. 

The default list is also used in the quick channel 
monitoring after an unsuccessful search of the current 
list has been made. Again, the default list is used only 
until a valid <SVP>-frame with the current list of system 
channels has been received from the new base station. 
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Measurement methods 

When the mobile terminal measures the received signal 
strength it can use two different measurement procedures: . 
FRAME or CONTINUOUS. Which of these it should use is 
stated by the parameter RSSI_PROC in the <SVP>-f rame. 

If RSSI_PROC states FRAME the mobile terminal measures the 
received signal strength of the frame heads received 
during the RSSI_PERIOD (stated in <SVP>). 

If RSSI_PROC states CONTINUOUS the mobile terminal 
measures the received signal strength during the entire 
RSSI_PERIOD. 

The parameter RSSI_PERlOD includes channel switching time, 
and has the default value 2 960 ms, with a tolerance of 
+/- 10 ms. 

During monitoring of current system channel and when 
making the final decision before chosing a new base, the 
terminal measures average received signal strength during 
the reception of frame heads. 
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Normal channel monitoring 

A mobile terminal measures the received signal strength 
from base radio stations on the CURRENT_SYSTEM_CHANNEL and 
calculates a roaming value for each base station. 

During each <SVP>-cycle (i.e. the time between two <SVP>- 
frames) the terminal leaves the CURRENT_SYSTEM CHANNEL for 
' a predefined period to monitor other channels and then 
return. These channels are chosen from the list of system 
channels (default or current). The start of the scan 
period depends on the terminal's own subscription number 
(MAN) being odd or even: 

scan start(odd) = TIME_TO_NEXT - 10ms -' 2*SCAN TIME 
scan start (even) * TIME_TO_NEXT - 10ms - SCAN TIME 



SCANJTIME = Length of predefined scan period, including 
_ ,.,...„ channel switching time. This is stated in 

the <SVP>-frame and has. the default value 3 
seconds, with a tolerance of +/- 10 ms.. 

TIME_TQ_NEXT = Interval between two <SVP>-f rames. This 

parameter is stated in the <SVP>-frarae and 
has the default value 10 seconds. 



ch #n : : let- 
ch #4 — — — Hri— 

ch #3 -Hrl 

ch #2 —Hrl 

ch #1 —Hrl 



where m = monitor current system channel 

s = scan other system channels 
r = RSSI_PERIOD 
e = evaluation 

The monitoring is cyclically repeated for all channels and 
every channel is monitored one RSSI_PERIOD. 

For example, if the RSSI_PERIOD and SCANJTIME have default 
values, the list contains 7 channels and the length of a 
<SVP>-cycle is 10 seconds, then the time between the scans 
of a specific channel from the list is 70 seconds. On the 
other hand, if the RSSI PERIOD is 4 (80 ms) and SCANJTIME 
is 30 (3 s) then the moEile will scan at least 30 channels 
during each <SVP>-cycle. 
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Criteria for leaving CDRR 


ENT BASE 



The mobile terminal leaves CURRENT BASE during a <SVP>- 
cycle if: ~ 

-1- roaming value (CURRENT_BASE) < BADJ3ASE 

BAD BASE is stated in the <SVP>-frame and its 
default value is 15. 

or 

-2- roaming value (best base) > 

roaming value (CDRRENT_BASE) + BETTER_BASE. 

If this criterion is fulfilled, the mobile should remain 
in normal channel monitoring on the current system channel 
for another <SVP>-cycle. During the next scan period the 
mobile should measure the average received signal strength 
of frame heads from best base. If the roaming value still 
fulfils the criterion, the mobile should select this base' 
as new CURRENTJBASE and the new channel as 
CURRENT_SySTEM_CHANNEL . 

The following figure shows an example where this criterion 
applies: 

roaming value 

best base 



CDRRENT_BASE 



30 

BETTER__BASE | 
BAD_BASE 15 



The parameter BETTER_BASE is stated in the <SVP>- 
frarae and its default value is 10. 



Exhibit 2, p. 569 



Cantel Mohitex~ 



9/1056 - A 296 5171/02 Oe 



1990-02-26 A 



The following criteria cause the mobile .to leave 
CORRENT_BASE immediately without waiting for the end of 
the <SVP>-cycle: 

-3- The terminal has made MAX_REP retransmissions 

without getting an acknowledgement from base. The 
value of MAX_REP is stated in the <SVP>-frame. 

-4- The terminal has received a <NAT> (including an 
order to leave the CURRENT_BASE) from base. 

And the last criterion applies when no traffic is 
exchanged: 

-5- The terminal has not received valid <SVP>- f rames 
within 2 <SVP>-cycles (= 2*TIME_TO_NEXT) . 



Any of the above criteria, except -2-, causes the mobile 
terminal to leave CURRENTJBASE and evaluate other bases.. 



Evaluation of other base stations 

MOB first evaluates the best base {? CURRENT_BASE) from 
the normal channel monitoring. This is done by evaluating 
the: 

roaming value from the last <SVP>-cycle (on 
CURRENT_S YSTEM_CHANNEL ) 

roaming value from the last RSSI_PERIOD of a 
specific channel (on the other system channels) 

If the base is on the CURRENT_SYSTEM CHANNEL and have a 
roaming value greater then GOOD_BASE it can be directly 
selected as CURRENT_BASE . 

But if the new base is on. a new system channel the mobile 
shall measure the average received signal strength during 
the reception of frame heads on this channel for 
SCAN_TIME. If the measured roaming value is greater then 
GOOD BASE, the mobile should select this channel as 
CURRENT SYSTEM CHANNEL and this base as CURRENT_BASE. 
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Quick channel monitoring 

If best base is not good enough, a quicker scanning 
procedure is adopted until a suitable base is found. MOB . 
then scans its list of (current) system channels in the 
fallowing way: 

-1- Begin with the first channel from the list. 

• -2- Measure the average received signal strength for 
RSSI_PERIOD. 

-3- If the measured roaming value is greater than 

GOOD_BASE remain on this channel. Otherwise skip to 
step 6. 

-4- Measure the average received signal strength during 
the reception of frame heads on this channel for 
SCANJTIME. 

-5- ..If the roaming value is greater then GOOD_BASE 

select this channel as CORRENT_SYSTEM_CHANNEL , the 
base as CURRENT_BASE and return to normal channel 
monitoring. Otherwise go to step 6. 

-6- Stop scanning if all channels of the list have been 
scanned, otherwise choose next channel from list and 
repeat steps 2-5. 

After MOB has scanned a number of channels from the list 
(please see reference Rl-06) , or the list is ended, the 
current system channel is scanned in the same manner. The 
scan of the list is then resumed, if the end of the list 
was not already reached. 

If the complete current list of system channels has been 
searched without a new base having been chosen, the quick 
channel monitoring is restarted with the default list of 
system channels. 



Re-establishing contact 

When a new CURRENTJ3ASE has been chosen, an <MRM>-frame 
with roaming information is sent to it. If the new BASE is 
identical to the old CORRENT_BASE, an <MRM>-frame with 
activation information is sent instead. 
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Area identification 

The frame header (on the physical layer) includes an area 
identification used to specify geographical areas. Such an 
area is denoted as a traffic area and is given a unique 
area ID by the network. 

From the network layer, the data link layer receives a 
list including the areas subscribed to by the user. The 
list also shows if the areas not subscribed to are allowed 
to be used, with for example higher charges, or not. 

From the physical layer, the data link layer receives 
information about incoming roam information, i.e. area ID, 
base ID and weighted roaming value. 

During the roaming procedure (described above), the 
terminal will 'primarily evaluate roaming information from 
bases belonging to the subscribed traffic areas. If the 
terminal is allowed to traffic other areas all bases may 
—be considered in the roaming procedure. — 

In case a "non-subscribed" base is chosen (possible only 
in quick channel monitoring), it should be notified to the 
application layer, as well as when the terminal returns to 
a "subscribed" base. 

If the terminal have not yet received the list of area 
IDs, the roaming procedure will evaluate all base 
stations. 
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4 . 4 ADDRESSING 



4.4.1 Addressing the base radio station 

The base radio station is only addressed in the frame 
head. Further details can be found in reference Rl-17. 



4.4.2 Addressing a mobile terminal 

Transmitting The mobile terminal's, subscription number 
(MAN) is always used as the HOB address. 

Receiving When receiving, the MOB address refers to 

the mobile terminal's MAN, or any MAN 
representing a group to which the terminal 
- belongs. (A transferred subscription is 
addressed in the MPAK.) 

■ — A MAN -representing a group occurs only 

when receiving frame types <MRM>, <BKD>, 
<BKT>, <BBT> and together with, a mask 
value of 0 in frame types <PRI>, <SVP>, 
<TST>. Masked addressing is described in 
detail in chapter 4.4,2.1. 

Masked and priority addressing is used in 
frame types <SVP> and <TST>. 

Masked, priority and traffic type 
addressing is used in frame type <FRI>. 
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4.4.2.1 Masked addressing. 

Masked addressing is only used in <SVP>, <FRI> and <TST>. 
In this addressing mode both the MASK and MOB fields of 
the frame are used. The MASK field indicates the number of 
bits from the beginning of the MOB field (most significant 
bits) that should not be considered (masked out) when 
comparing the MOB field with the terminal's MAN. 

A MASK value different fromO (zero) indicates that only 
the terminal's own MAN is to be compared with the relevant 
bits of the MOB field. 

A MASK value of 0 {no bits masked out, all bits of MOB are 
relevant) indicates that the MOB field is to be compared 
with both the terminal subscription MAN and with the MANs 
of all current group numbers in the group list. 

The terminal is considered to be addressed if all relevant 
bits of the MOB field are the same as the corresponding 
-bits .•-o£-=one of the compared MANs. 

A MASK value of 24 (decimal) .indicates that all bits are 
masked out and that all mobile terminals are addressed. 

Note: For <SVP> and <TST> signals the priority of the 

terminal must also comply with that of the signal. 

For the <FRI> signal the priority and traffic type 
of the terminal must comply with that of the signal 
for the terminal to be addressed (except for 
emergency where priority is ignored). 
(See below) . 
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Example: Assume a frame with the following contents in the 
HOB and MASK fields. 




(x indicates that the corresponding bit is to be 
ignored) 




MOB Eield Bit no. : 
Value : 


1 24 
101000000000101010110010 




MASK field Bit no. 

Value 


: 15 

s 11000 (24 decimal) 




Addressed MAN Bit no. : 1 24 




Value : xxxxxxxxxxxxxxxxxxxxxxxx 
All mobile terminals are addressed. 




MASK field Bit no. 
=.,. . Value 


: 1 5 

: 10111- (23 decimal). 




Addressed MAN Bit no. : 1 24, 
Value : xxxxxxxxxxxxxxxxxxxxxxxO 




Only 'mobile terminal subscriptions with MAN 
ending with binary 0 are addressed. 




MASK field Bit no 
Value 


: 1 5 

: 10110 (22 decimal) 




Addressed MAN Bit no. : 1 xxxxxxxxxxxxxlO* 




Only mobile terminal subscriptions with MAN 
ending with binary 10 are addressed. 




MASK field Bit no 
Value 


5 1 5 

s 00000 (0 decimal) 




Addressed MAN Bit no.: 1 24 
Value : 101000000000101010110010 




The MASK value 00000 (zero) indicates that 
mobile terminals with the terminal 
subscription HAN, or any of its MAN numbers 
representing groups, identical to the MOB 
field are addressed. 
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4.4.2.2 Priority addressing 

Priority addressing is used in the frames <SVP>, <TST> and 
<FR1> . 

A terminal subscrir»tion belongs to one of 4 priority 
groups. The terminal may have two priority states within 
each group, normal or raised. The terminal will raise its 
priority if it has made MAX_REP retransmissions of the 
same frame without getting any acknowledgement from the 
base station. 

PRIQ field 



-rnr 

110 
101 
100 
011 
010 
001 
000 



Meaning 

Priority group 4, 



raised priority 
. normal 

Priority group 3, raised priority 
" * , normal 
Priority group 2, raised priority 
" , normal 
Priority group 1, raised priority 
" , : normal 



When receiving a frame with priority addressing, the 
mobile terminal is addressed if its own priority is higher 
than or same as the received priority. 

If the terminal is to transmit an emergency signal the 
priority level is ignored. 



A232S15M 
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4.4.2.3 Traffic type addressing 

Traffic type apniies to the type of MPAK to be sent from 
the mobile terminal. The packets are separated into 3 
traffic types: 

emergency: MPAK class PSOSCOM 

speech: MPAK class CSOBCOM 

data: All other types of MPAK 



Traffic type addressing is used only in the <FRI> frame. 
The traffic type to which the <FRI> applies is coded into 
the FFG field as follows: 



Value 


Emerqency 


Speech 


Data 


00 


yes 


no 


no 


01 


yes^— _ 


no 


yes 


10 


yes 


yes 


no 


11- 


yes 


yes 


yes 



Note: For the frames <SVP> and <TST>, both the masked 
address and the priority must be correct for the 
terminal to be addressed. 

For the <FRI> to be valid, the masked address, the 
priority and the traffic type criteria must be met 
by the terminal, except for the transmission of an 
emergency signal where only the masked address and 
traffic type criteria has to be met (priority is 
ignored) . 
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4.5 SEQUENTIAL NUMBERING 

The transmitting unit repeats the transmission of a frame 
if there is no response from the receiving unit. This 
means that the receiving unit can receive identical frames 
if its resnonse is not detected by the transmitting unit. 
To avoid repeated presentation of information, certain 
types of frame are given sequential numbers. The principle 
is as follows. 

The terminal sets up a sequential register for the 
terminal subscription MAN (up and down sequential 
number) and for each of the MANs stored in 
GHOOP_LIST (only a down sequential number for each). 

A sequential number is an integer with a value in 
the range (0...15). The sequential numbers are 
incremented cyclically 1, 2, 3...., 14, 1, 2, 3 etc. 
The values 0 and 15 are reserved for special 
purposes . 

- The utT^eWehtiaT number applies to frames 

transmitted in the direction from MOB to BASE. The 
up sequential number is increased by one by the 
mobile terminal for each new <MKM>-frame 
transmitted. 

MOB which receives a sequentially numbered frame 
checks the sequential number of the frame against 
the stored down sequential number for the 
corresponding MAN. If the received sequential number 
is the same (and not 0, see below), the information 
in the frame is ignored. If the sequential number is 
not the same (or 0, see below), the frame is 
accepted and the sequential number of the received 
frame is stored (except for 15, se below). The 
number is stored when acknowledgement of the frame 
has been sent. 

On reception, the value 0 for a sequential number 
means that a sequential number check should not be 
carried out on the frame and that the value 0 should 
be stored in the terminal as the new down sequential 
number . 

On reception, the value 15 for a sequential number 
means that a sequential number check should not be 
carried out on the frame and that the old down 
sequential number remains. 
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The up and down sequential numbers are set to 0 when not 
defined (e.g. at initial start up). 

Down sequential numbers for group numbers are reset to 0 
when roaming in on a new base station. 

Also returned packets with status DNKNOWN should have a 
sequential number. 

When the mobile is transmitting the following types of 
packets, the sequential number 15 should be used: 

CSUBCOM:DISCON 

CONREA 
DTESERV: ACTIVE 

INACTIVE 

ROAM 
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4.6 OUTPOT POWER CONTROL 

The MOBITEX system allows for mobile terminals to control 
the output power via oarameters in the system signalling, 
from the base radio station. Network operator requirements 
concerning this matter is stated in reference Rl-06, as 
well as the nominal output power. 

Requirements, such as the number of output levels to be 
controlled by the mobile terminal and in what steps the 
levels should be controlled, is also stated in reference 
Rl-06. 

The mobile terminal receives information about the output 
power to be used in the base station cell in question. 
This is stated by the parameter TXPOW in the <SVP>-frame. 

Portable transmitters may have lower output power than 
ordinary transmitters. Note that the receiver sensitivity 
should be reduced or an offset should be added to the 
parameters GOOD BASE and BAD_BASE used m the roaming 
procedure. This~is done in order to keep the same ratio 
between the permitted transmission losses in the send and 
receive directions, i.e. to maintain a balanced radio 
path. 

For example, if the power of the transmitter is 10 dB 
lower than the specified level, the receiver sensitivity 
could be reduced by 10 dB from the specified sensitivity 
level. Instead of reducing the sensitivity, an offset of 
10 can be added to the parameters GOOD_BASE and BAD_BASE. 
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4.7 LOGICAL DESCRIPTION 

The data flow diagram below shows the interaction between 
modules in the Data Link Layer and between this layer and 
the Network and Physical Layers. 



[Application Layer { 



Network Layer 



Packet handling (PAHA) 



1 






1 


i 


Processing -in- 
coming frames 
(IFRA) 




Processing out- 
going frames 
(OFRA) 
















7 i 














Input and 
decoding- (DCOD) 




Coding and 
output (CODE) 


Base contact 
monitoring 


3 ' 














' 4 ' 


' 5^ 


' 6 < 


1 7 



Physical Layer 



-1- MPAK transmitted, MPAK not transmitted, HPAK received, 

roaming, activation 
-2- MPAK to transmit, MPAK to retransmit, speech on, 

speech off, order to return MPAK, list of area IDs, 

list of group numbers 

Signals to/from Physical Layer: 

-3- Received block, Sync search 
-4- Frame to send, Frame length 

-5- Slot length, Chosen slot. Slot reached. Silence, 

Cannot send 
-6- Current base, Frame sent 
-7- Received base, Measure_RSSI, RSSIjneasured 

Signals to the Application Layer: 

-8- Speech queue info, base lost, base contact, area 
subscribed to chosen, area not subscribed to chosen 
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4.7.1 Input and decoding (DCOD ) 

DCOD converts the bit stream from the physical layer into 
frames. It decodes the blocks of these frames and checks 
that the frames are addressed to the terminal. 



4.7.1.1 Logical description 



wait for information bits from Physical Layer 
read and decode first block 
IP first block is correct THEN 
CASE frame type 

WHEN <ACK> , <NAK> , <ATL> , <ATD> , <ATT> , £NAT > or <VKT> 
IF frame address ■. terminal address THEN 

send frame to OPRA 
ENDIF 
WHEN <REB> 

IF. frame address = terminal address THEN 
read and decode remaining blo cks of frame 
IF frame is error-free THEN 

send frame to OFRA 
ENDIF 
ENDIF 

WHEN <FRI>, <SVP> or <TST> 

IF (frame address with mask = terminal address) OR 
(mask=0 and address » a group address) THEN 
read and decode remaining blo cks of frame 
IF frame is error-free THEN 

send frame to OFRA 
ENDIF 
ENDIF 

WHEN <AKT> or <RES> 

IF frame address = terminal address THEN 

read and decode remaining blocks of frame 

send frame to IFRA 
ENDIF 

WHEN <MRH>, <BKD>, <BKT> or <BBT> 

IF (frame address = terminal address) OR 
(frame address = a group address) THEN 
read and decode remaining blocks of frame 
send frame to IFRA 
ENDIF 
ENDCASE 
ENDIF 

send sync_search order to Physical Layer 



a.prM. 



ASMS1SM 
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4.7.2 Processing incoming frames (IFRA ) 

IFHA handles the received frames from DCODi If a received 
<MHM> is not error-free, IFHA requests a repeat 
transmission of the faulty blocks until a correct <MRM> 
has been received and acknowledged. 



4.7.2.1 Logical description 



wait for frame from DCOD 
CASE frame type 
WHEN <MRM> 

IP we have <MRM> waiting for <RES> THEN 
delete that <MRH> 

ENDIF 

IF response required THEN 

IF <MRM> is error-free THEN 

create <ACK> and send it to CODE 

send <MRM> to- 5 AHA 
ELSE 

IF <MRM> is shorter .than 3 blocks THEN 

create <NAR> and send it to CODE 
ELSE 

create <REB> and send it to CODE 
store <MRM> while waiting for <RES> 
ENDIF 
ENDIF 
ELSE 

IF <MRM> is error free THEN 
send <HRM> to PAHA 

ENDIF 




retrieve stored <HRM> 

IF sequenti al n umber = stored <MRM>:s sequential 

number THEN 
complete <MRM> with error fre e blocks from <RES> 
IF <MRM> is error free THEN 

create <ACK> and send it to CODE 

send <MRM> to PAHA 
ELSE 

create <REB> and send it to CODE 
store <HRM> while waiting for <RES> 
ENDIF 
ENDIF 

WHEN <BKT>, <BKD> or <BBT> 
IF frame is error free THEN 
• send frame to PAHA 
ENDIF 
WHEN <AKT> 

create <ACK> and send it to CODE 
ENDCASE 
ENDLOOP 
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4.7.3 Processing outgoing frames (OFRA) 

OFRA handles the sending of frames. It must wait for 
permission to send,, decide whether an access request is to 
be sent first etc. 

OFRA receives <MRM>-f rames of traffic types emergency, 
speech or data from PAHA. It returns them co PAHA with a 
statement of whether acknowledgement of the frame has been 
received or not. PAHA can also request that OFSA should' 
cease trying to transfer the frame. 

If the Data Link Layer is in speech_mdde, an <MRM> may be 
sent immediately. This is done with a timeout that is 
independent of any free cycles. 

OFRA is capable of handling only one <MRM>- frame at a 
time. 



.4.7.3.1 



Logical description. 



LOOP 

wait for input signal 

CASE -input signal 

WHEN new <MRM> from PAHA 

IF (free cycle is running) and {priority and traffic 
type allows transmission) THEN 
choose next free slot 

store <MRM> while waiting for slot_reached 
ELSE 

IF speechjmode THEN 

send copy of <MRM> to CODE for transmission 

speech mode timer := 2 seconds 
ELSE 

store <MRM> while waiting for permission to send 
END IF 
ENDIF 

cancel_request := FALSE 

WHEN STOP_SEND from PAHA 

return <MRM> to PAHA with status 'discontinued' 
IF speech_queue THEN 

IF free cycle is running THEN 

choose next free slot 
ENDIF 

speech_queue := FALSE 
cancel_request := TRUE 



IHEN SPEECH_TRDE from PAHA 
speech_mode := TRUE 
speechjgueue := FALSE 

HEN SPEECH_FALSE from PAHA 
speechjnode := FALSE 
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WHEN timeout of speech_mode_timer 

return <MRM> to PAHA with status 'failed' 

WHEN <ACK> from DCOD 

IF sequential num ber in <ACK> = sequential number in 
latest <MRM> THEM 

return <MRM> to PAHA with status 'OK' 
disable speech mode timer 
ENDIF 

WHEN <NAK> from DCOD 

IF sequential num ber in <NAK> = sequential number in 
latest <MRM> THEN 
send copy of latest <MRM> to CODE for transmission 



HEN <REB> from DCOD 
IF sequential number in <REB> = sequential number in 
latest <MRH> THEN 
create <RES> and send it. to -CODE for .transmission 



HEN <FRI> from DCOD 
update free signal parameters 
IF we have <MRM> waiting for <RES> THEN 

delete that <MRM> 
ENDIF 

IF cancel request THEN 

choose a~random free slot 
ELSE 

IF we have <MRM> to send THEN 

IF priority and traffic type allows transmission 
THEN 

IF NOT speech queue THEN 

IF we have alr eady repeated <MRM> MAX_REP 
times THEN 
return <HRM> to PAHA with status 'failed' 
ELSE 

choose a random free slot 
store <MRH> while waiting for slot_reached 
ENDIF 
ENDIF 
ELSE 

store <MRH> while waiting for permission to send 
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WHEN <ATD> from DCOD 

IP we have data <MRM> to send THEN 

send copy of <MHM> to CODE for transmission 
ENDIF 

WHEN <ATT> from DCOD 

IF we have speech <MRM> to send THEN 

send copy of <MRM> to CODE for transmission 
ENDIF 



WHEN <NAT> from DCOD 

IF we have speech <MRM> to send THEN 
IF order to leave CURRENT_B AS E THEN 

return. <MHM> to PAHA with status 'failed' 
ELSE 

return <MRM> to PAHA with status 'no channel' 
ENDIF 
ENDIF 

speech_queue := FALSE 

WHEN . .. <ATL>_..f I om. DCOD 

IF we have emergency <MRM> to send THEN 

send copy of <MRM> to CODE for transmission 
ENDIF 

WHEN <SVP> from DCOD 

IF (sub type 1 or 2) and (priority is the same as or 
less than terminal priority) .. THEN 
send <SVP> to PAHA 
ENDIF 

WHEN <TST> from DCOD . 
send signal to Physical Layer that we cannot_send in 
any slot 

WHEN <VKT> from DCOD 
speech_queue := TRUE 
queue timer := timeout value 

send signal SPEECH_QUEOE_INF0 to Application Layer 

WHEN timeout of queue^timer 
speech_queue : = FALSE 

WHEN SILENCE from Physical Layer 

send signal to Physical Layer that we cannot_send in 
any slot 
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IF we have <MRM> to senc 
CASE <MRH> traffic type 
WHEN emergency 

IF <MRM> contains more blocks than MAX_ACCESS 

^"create <ABL> and send to CODE for transmission 
ELSE 

send copy of <MRM> to CODE for transnu.ssi.on 
ENDIF 
WHEN speech 

IF cancel request THEN 

cancel request := FALSE 

create <AAT> and send to CODE for transmission 
ELSE mTTTO 
IF <MRM> with line connection request THEN 
IF <MRM> contains more blocks than MAX_SPEECH 
THEN 

create <ABT> and send to CODE for 
transmission 

ELSE , , 

send copy of <MEM> to CODE for transmission 
ENDIF 
ELSE 

send copy of <MRM> to CODE for transmission 



create <ABD> and send to CODE for transmission 
ELSE 

send copy of <MRM> to CODE for transmission 
ENDIF 
ENDCASE 

increment counter of .attempts to send 
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4.7.4 Coding and readout (CODE ) 

CODE codes the blocks of the frame and transfers the bits 
to the Physical Layer. 



4.7.4.1 Logical description 
LOOP 

Wait for frame to transmit 
Code the blocks of the frame 
Transfer the bits to the Physical Layer 
ENDLOOP 



Exhibit 2, p. 



40 



Cantel Mobitex- 



S 9/1056 - A 296 5171/02 Oe 



"l990-02-26 A 



MTS16 . 2 



4.7.5 Base contact monitoring (BMON ) 

BMON monitors contact with the base station(s) and works 
in 3 different modes: 

-1- Normal Channel Monitoring 

-2- Quick Channel Monitoring 

-3- Disabled 

For further information, see chapter ROAMING. 

Input signals coma from the Physical Layer and from PAHA: 



-1- no_base_contact 
best_BASE 



PAHA 



1 



2 



-2- set_mode_l 
set_mode_2 
set_mode_3- 



-3- received_base 



BMON 



3 



Physical 
Layer 



A 292 SUM 
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4.7.6 Packet handling (PAHA ) 

PAHA handles the conversion between MPAKs and <mrm>- 
frames. It supervises the contact with BASE and informs 
the network when changing BASE and when returning after 
lost contact with the network. 



PAHA is only capable of handling i 
works in three different modes: 



Normal mode 



: MPAK at a time and it 



• Contact with a base station is 
established and the Network Layer may 
send and receive all types of MPAK. 

■ PAHA enters this mode only on order 
from the Network Layer. The Network 
Layer also decides which MPAKs that may 
be sent. PAHA leaves the speech mode on 
order from the Network Layer or when 
the transmission of an <MHM> has 
failed. 

■ When base contact is lost, PAHA enters 
base search mode. MPAKs from the 
Network Layer are not handled in. this 
mode. When a base has been located, 
PAHA returns to normal mode. 

The mobile terminal returns to the relevant system channel 
after the end of all sessions on other channels 
(channel_for_sending_speech, channel_for_sending_data) . 



Speech mode 



Base search mode • 
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Logical description, main program 



IF an old base is saved THEN 
send set_mode_l to BM.ON 
system_channel := current_syscem_channel 
OFRA_scatus := free . 
main_mode := normal_mode 

main_mode := base_search_mode 

ENDIF 



LOOP 

CASE mainjnade 
WHEN normaljraode 

normal 
WHEN speech_mode 

speech 
WHEN base_search_mode 

base_search 
ENDCASE 
ENDLOOP 
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4.7.6.2 Logical description, normal (norraaljnode) 




WHILE main mode = normaljaode 
wait for Input signal 
CASE input signal 




WHEN MPAK TO TRANSMIT from Network Layer 
create <MRM> with new up sequential number 
IP access channel opened THEN 

change to access channel 

channel := channel for_sending_data 
ENDIF 

send <MHM> to OFRA 
OFRA_status := busy 




WHEN MPAK TO RETRANSMIT from Network Layer 
create <MRM> with old up sequential number 
IF access channel opened THEN 

change to access channel 

channel := channel for sending data 
ENDIF 

send <MRM> to OFRA 
OFRA_status := busy 




WHEN SPEECHjON from Network Layer 
raainjnode := speech_mode 




WHEN RETORN_MPAK from Network Layer 
send stop send to OFRA 
wait to get frame that was in progress 
return <MRM> to Network Layer with status 'not 
transmitted' 




WHEN <SVP> from OFRA 
CASE sub type 
WHEN 1 






update parameters 






CASE type of channel 

WHEN local system channel opened 
system channel := local 
change to new system channel 

WHEN local system channel closed 
system channel := previous 
change to new system channel 

WHEN access channel opened 
store access channel 

WHEN access channel closed 
delete access channel 
■ ENDCASE 
ENDCASE 


feproo 
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WHEN <BKT> from IFRA 

IP acknowledgement of <MRM> THEN 

send <ACK> to OFRA 
ELSE 

start timer with timeout value 
ENDIF 

channel := channel_for_speech 
change to designated channel 
send set_mode_3 to BHON 

WHEN <BKD> from IFRA 

IF it is a channel change to send frame THEN 

channel := channel_for sending_data 
ELSE 

channel := channel_for receiving_data 
ENDIF 

start timer with timeout value 
change to -designated channel 
send set_mode_3 to BMON 

WHEN timeout for change of channel 
change to system_channel 
send set_mode_l to BMON 

WHEN <BBT> from IFRA 

store new parameters and change channel 

WHEN <MRtt> With status 'OK* from OFRA 
OFRA status := free 

return MPAK to Network Layer with status 'transmitted' 
priority := normal 

IF channel = channel_for_sending_data THEN 

change to system_channeT 

send set_mode 1 to BHON 
ENDIF 

reset timer for change of channel 

WHEN <MRM> with status 'failed' from OFRA 
OFRA status := free . 

return MPAK to Network Layer with status 'not 

transmitted" 

priority := raised 

mainjnode :=> base_search mode 

reset timer for change oF channel 

WHEN <MRM> with status 'no channel' from OFRA 
OFRA_status := free 

return MPAK to Network Layer with status 'not 

transmitted' 

priority := raised 

reset timer for change of channel 
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WHEN incoming <MRM> from IFRA 
CASE incoming sequential number 
WHEN 0 




check ok := TRUE 
store""riew down sequential number 
WHEN 15 

check ok := TRUE 
WHEN OTHERWISE 

IP different from last seq. number received THEN 
check_ok := TRUE 
stors"new down sscjusntisl number 

^check ok := FALSE 
ENDIF 




ENDCASE 

IF check ok THEN 

IF channel = channel for receiving_data THEN 
IF response NOT required THEN 
change to system_channel 
send set_mode_l to BMON 




ENDIF 
' ENDIF 

send MPAK to Network Layer . 




delete <MRM> 






reset timer for change of channel 




WHEN Frame sent from Physical Layer 
IF frame = <ACK> THEN 

IF channel = channel_f or_receiving_data THEN 
change to system channel 
send set mode 1 to BMON 




ENDIF 

reset timer for change of channel 
ENDIF 




WHEN no base contact from BMON 
IF OFRA status = busy THEN 

send stop send to OFRA 

wait to get frame that was in progress 

return <MRM> to Network Layer with status 'not 

transmitted' 
ENDIF 

main mode := base_search_mode 




ENDCASE input signal 
ENDWHILE 
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4.7.6.3 Logical description, base search (base search 
mode) 

wait for input signal BEST_BASE from BMON 
IF roaming value > GOOD_BASE THEN 

CURRENT_3ASE := new base 

CURRENT_SYSTEM_CEANN£L := new channel 

send signal ROAMING to Network Layer 

clear sequential numbers for all groups 

delete access channel 
ELSE 

send signal BASE_LOST to Application Layer 

send order set mode_2 to BMON 

REPEAT 

wait for input signal BEST_BASE' from BMON 
UNTIL roaming value > CHOOSE BASE 
IF base = CORRENT_BASE THEN 

send signal ACTIVATION to Network Layer 
ELSE 

CURRENT_BASE := new base 

C0RRENT_SYSTEM_CHANNEL i= new channel, 
send signal ROAMING to Network Layer 
clear sequential numbers for all groups 
delete access channel 
ENDIF 

send signal BASE_CONTACT to Application Layer 
ENDIF 

send set mode_l to BMON 
mainjnode := normaljnode 



A.29SM5M 
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4.7.6.4 Logical description, speech (speech mode) 




send speech_true to OFRA 






WHILE mainjnode = speech_raode 




CASE input signal 

WHEN speech off from Network Layer 

wait 0.5 seconds 

change to system channel 

send set mode 1 to BMON 

send speech false to OFRA 

mainjuode := norma l_mode 




WHEN new MPAK from Network Layer 

create <MRM> with new up sequential number 
send <MRM> to OFRA 
OFRA_status := busy 




WHEN MPAK from Network Layer to be retransmitted 

create <MRM> with old up sequential number 
send <MRM> to OFRA .. . 
OFRA_status := busy 




WHEN <MRM> with Status 'OK' from OFRA 
OFRA status := free 

IF <MRM> with CSUBCOM:DISCON THEN 
change to sy3tem_channel 
send set mode 1 to BMON 
send speech_false to OFRA 
raain_raode : = normal_raode 




return MPAK to Network Layer with status 'transmitted' 




WHEN <MRM> with status 'failed' from OFRA 

change to system channel 

send set mode 1 to BMON 
• send speech false to. OFRA 

main mode := normal mode 

IP <MRM> with CSOBCOM:DISCON THEN 
send <MRM> to OFRA 

ELSE 

OFRA_status := free 

return MPAK to Network Layer with status 'not 
transmitted' 
ENDIF 




WHEN <BBT> from IFRA 

store new parameters and change channel 
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WHEN incoming <HRM> from IPRA 
CASE, incoming sequential number 
WHEN 0 

send MPAK to Network Layer 
store new down sequential number 
WHEN 15 

send MPAK to Network Layer 



IF different from last seq. number received 
send MPAK to Network Layer 
store new down sequential number 

ELSE 

delete <MRM> 

ENDIF 
ENDCASE 

WHEN signal from BMON 
ignore this signal 
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TRANSFER EXAMPLES 



This chapter describes the most 
the protocol. 



transfer cases of 



4.8.1 Transfer without response 

Transfer without response can only take place in the 
direction BASE to MOB. 

In traffic to mobile terminal! s) BASE often addresses more 
than one MOB. This can apply to traffic to group numbers 
or frames where masked addressing occurs. In these cases 
MOB will not transmit a response. BASE states this by not 
setting the response flag in these frames. 



Ex 1;1 



Transfer without response, <MRM> BASE — > MOB 




-> t 
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Transfer with simple acknowledgement 



BASE has full control over the down frequency and can 
transmit an <MRM>-frame at any time to a certain MOB. If 
the response flag is set and no incorrigible bit error has 
been detected in the frame, MOB should reply with <ACK>. 



Transfer with response, <MRM> BASE — > MOB 

BASE <MRM> 

MOB <ACK> 

> t 



Note that <ACK> is sent without considering slot 
boundaries and other access limitations. 



Transfer with response, <MRM> 


MOB - 


•--> BAS 


E 


BASE <FRI> <ACK> 
MOB <MRM> 











By transmitting <FRI>, BASE allows MOB to transmit <MRM>. 

In this case MOB expects an acknowledgement from BASE. The 
lack of an acknowledgement is indicated in this case by 
MOB receiving a <FRI> without having previously received 
acknowledgement of its frame. Frame repetition follows in 
this case. 

Free slots is defined, and thus access permission to the 
up channel is granted, when BASE transmits a <FRI> with an 
address that is applicable to MOB. Access permission is 
withdrawn for a certain MOB if any of the following cases 
arise. 

1 BASE transmits a silence signal (see reference 
Rl-17). This signal applies to all terminals. 

i address which applies 

The free-cycle period as defined in the <FRI>-signal 
expires. 



A 212315&3 
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4.8.3 Transfer with block repetition 

If the receiver of -an <MRM> detects that one or more of 
the following blocks is incorrigible, the receiver may 
request repetition of these blocks with a <REB>. The 
sender replies with a <RES>. 

NOTE Block repetition occurs only on <MRM>-f rames where 
the number of blocks is 3 or more. 



Transfer with block repeat, MOB > BASE 

BASE <REB> <ACK> 

MOB <MRM> <RES> 

> t 



The principle described in the figure above applies in the 
direction to BASE and in the direction to MOB. 
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4.8.4 Transfer with frame repetition 




Frame repetition can occur for three reasons: 




1 The receiving unit transmits a <NAK> 




2 The receiving unit does not transmit a response 




3 The packet type results in frame repetition 




EX 4.1 








Transfer with negative 


acknowledgement MOB > BASE 








BASE < MRM > 

MOB <NAK> 


<MRM> 

<ACK> 

> t 






If the receiving unit finds that the received frame is 
incorrectable and is less than 3 blocks, it can notify the 
sender unit by transmitting a <NAK>. The transmitting unit 
should then repeat the message. The principle above 
applies in both transmission directions. 




The frame is- repeated immediately after an <NAK> is 
received, regardless of slot boundaries. 




1 


:x 4.2 








Transfer with frame repeat, MOB > BASE 








BASE <EHI> <ACK> <FRI> <ACK> 
HOB <MRM> <KSH> 

xxxxx > t 






In this example the first acknowledgement from BASE is 
destroyed by interference so that MOB retransmits the same 
message after the next free signal. 











A2S2SU3.3 
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Ex 4.3 



Transfer with frame repeat. 



BASE > MOB 



BASE 
MOB 



< MRM > 



<MRM> 



t 



In this example, frame repeat is caused by the packet type 
demanding repeated transmission. The response flag is 
never set in this case. 

This case occurs for MPAK to group numbers. To avoid 
repeated presentation of the information in the frame, the 
frame has got a sequential number. According to the 
principles for sequential numbering, MOB will ignore 
subsequent identical frames. 

NOTEl At the restart of a base radio station, the 



sequential numbers for all groups are set to 0. This 
is done to ensure that mobiles will not loose the 
first message to a group. The consequence of this 
action will be that the first" message may be 
presented MAX REP + 1 times at the- mobile terminal. 



Exhibit 2, p. 



Cantel Mobitex- 



9/1056 - A 296 5171/02 Oe 



1990-02-26 A 



4.8.5 Transfer with access request 



If an <MRM>-frame to be sent from MOB to BASE is longer 
than MAX_ACCESS this <MRM> may not be sent during free 
slots. These longer frames are handled with access 
request, <ABD>, and access permission, <ATD>. 



Transfer with access request, MOB" > BASE 

BASE <FRI> <ATD> <ACK> 

MOB <ABD> ' <MHM> 



The principle is that instead of MOB transmitting its 
<MRM>-frame, it transmits an <ABD>-frame. The reply to. 
this request is an access permission, <ATD>. When MOB 
receives access permission, it immediately starts 
transmitting the <MRM>. 



Repetition with maxjrep, MOB — > BASE 

BASE <FRI> ,.<FRI> . ...<FRI> 

MOB <ABD> <ABD> ' 



When the number of transmitted access requests is 
equal to MAX REP+1 and another <FRI> is received, the 
MPAK is returned to the network layer and a new base 
is chosen. 



Exhibit 2, p. 



Cantel Mobitex- 



9/1056 - A 296 5171/02 Ue 



1990-02-26 A 



Transfer with line connection 



The line connection session is described in reference 
Rl-09. When HOB wants to send an <MRM> (containing a 
request for a line connection) longer than MAX_SPE£CH it 
must request access for this. The access request results 
in a channel change order. On the new channel the session 
for frames takes place to establish the line connection. 
When the line connection is concluded MOB returns to the 
system channel. 



EX 6.1 



Transfer with line connection 






BASE cl <FHI> <BKT> 








BASE c2 


<ATT> <ACK> 






MOB Cl <ABT> 








MOB C2 


<MRM> 






tl t2 t3 













tl: Disable roaming and start timeout with time from 

<BKT>. 
t2: Stop timeout. 

t3: Speechjon received from Network liayer. 
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4.S.7 Transfer on several channels 

Transfer on several, channels can be divided into two 
separate cases: 

1 MOB apoears on another channel because BASE has 
stated* in a <SVP>-frame that all traffic from a 
mobile terminal shall be sent on a channel other 
than that on which the <SVP> came. 

2 BASE transmits a <BKD>-frame as .a reply to an <ABD>. 



EX 7.1 



Transfer on several channels 

BASE cl <FRI> <BKD> 
BASE c2 <ATD> 
MOB cl <ABD> 
MOB C2. <M 
tl 


<ACK> 

RM> 

t2 







tl: Disable roaming and start timeout with time from • 
<BKD> . 

t2: Return to system_channel, enable roaming. 



In this example, the access request from MOB resulted in a 
channel change order. The access permission is transmitted 
on channel c2. After having received an acknowledgement, 
MOB returns to channel cl. 
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4.8.8 Line connection 


with hand over 





Ordinary line connection 

BASEl,cl <FRI> <BKT> 
BASEl,c2 <ATT> 
MOB, cl <ABT> 
MOB, c2 



speech 
speech 



tli Ordinary connection established. 



EX 8.2 



Continued with <BBT> 




BASE2,cl 










BASE2,c3 




. . speech . 


<ACK> 




BASEl,cl 








BASEl,c2 


<BBT> 








MOB, cl 










MOB, c2 










MOB, c3 




.. speech . 


DISCON 




t2 t3 t4 


t5 










>t 



t2: Hand over to base 82. 

t3: MOB connected to base B2 on new speech channel, new 

system channel stored for later use. 
t4: MOB breaks connection and changes to the new system 

channel. 
t5: Connection ended. 
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4.8.9 Line connection with queue handling . 



If no speech channel is immediately available, BASE 
may place MOB in a queue of callers and reply with 
<VKT>. 



Succesfully established line connection 
BASE1,C1 <FRI> <VKT> ... <BKT> 

BASEl,c2 <ATT> <ACK> speech 

MOB, cl <ABT> 

MOB, c2 CONREQ . speech 



tl-t2: Waiting time. 

t3: Connection established. 



Call attempt ended by BASE 

BASE1 , cl <PRI> <VKT> J ... I <NAT> I 
MOB, cl <ABT> I... I I 

tl t2 t3 



tl-t2: Waiting time. 

t3: Call attempt ended. 



Call attempt ended by MOB 

BASE1 , cl <FRI> <VKT> I ... I I 
MOB, cl <ABT> I ... I <AAT> I 

tl t2 t3 



tl-t2: Waiting time. 

t3: Call attempt ended. 
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Call attempt ended by MOB 

BASE1 , Cl <FRI> <VKT> I ... I <VKT> I 
MOB, Cl <ABT> I... I I 



tl-t2: Waiting time. 
t3-t4: Waiting time. 
tS: Call attempt ended. 
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4.8.10 Line connection without access request 



When MOB wants to send an <MRM> (containing a 
request for a line connection) shorter than or equal 
to MAX_SPEECH no access request is needed. 

The response to the <HHM> is a channel change order 
that includes an acknowledgement. The line 
connection is immediately established on the new 
channel. 



EX 10.1 



Line connection without access request 

BASE Cl <FR1> <BKT> 

BASE c2 . . speech . . 

MOB cl <MRM> 

MOB c2 .. speech .. 

> t 



4.8.11 Ending a line connection 

An <MRM> with a DISCON may be transmitted only once 
on the speech channel. If MOB have not received 
<ACK> within 2 seconds, it changes to the system 
channel and continues the transmission attempts 
according to the usual rules. 



Ending a line connection 
BASE cl 

BASE c2 . .speech. . . 
MOB cl 

MOB c2 ..speech., DISCON 



<FRI> <ACK> 
DISCON 
tl t2 t: 



tl-t2: Timeout. 

t2: ■ Return to system_channel, enable roaming. 
t3: Connection ended. 
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4.8.12 Line connection ended by speech off 



After the mobile terminal has received an <MRM> 
containing a line connection request, the session 
may be put to an end by the signal speech_off from 
the network layer. This signal is generated by a 
timeout (please see reference Rl-09) when che 
operatdr has not answered the call. 



Connection ended by signal speech_off 



BASE cl <BKT> 
BASE c2 
MOB cl 



tl: Disable roaming and start timeout with time from 

<BKT>. 
t2: Stop timeout. 

t3: Speech_off received from Network Layer. Return to 
system channel and enable roaming: 
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5 SYSTEM PARAMETERS TO BE STORED IN THE TERMINAL 

Certain svstem parameters are stored continuously (even if 
the terminal is powered off) in MOB to permit correct 
action whan starting up. These are: 

The terminal subscription MAN 

Grouo number list (GROOPLIST) 
Maximum number of retransmissions allowed (MAX_R£P) 
Sequential numbers - terminal MAN (up/down) 
Current base 
Current system channel 

A list of the area identifications that the mobile 
is allowed to use. Please see reference Rl-06. 

When switched on, all these parameters apply until a frame 
is received containing the current parameter values. 

There is also a permanent (and possibly a temporary) 
default list of system channels used by the roaming 
algorithm. They are stored continuously and have the 
following general format: 



channel 


#1 




channel 


#n 



total number of channels (2 bytes) 
system channels 



A channel is defined as a pair of frequencies and all the 
channels of this list are given in reference Rl-06. 
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6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 17, 22, 31, 62 
Rl-09, 4, 7, 55, 61 
Rl-17, 5, 14, 17, 24, 50 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

R1-Q3 General description of terminals ....... . . 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 • Application layer 

Rl-09 Network layer- 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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MOBITEX 

Data Link Layer, Mobile Terminal 
Appendix A, Frames? 8/16 kbps 



ABSTRACT 

This document describes frame structure and coding for the 
Data Link Layer. 
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1 INTRODUCTION 



1.1 GENERAL 



The mobile terminal's Data Link Layer together with the 
Physical Layer form a radio protocol for communication 
between mobile stations (HOB) and a base radio station 
(BASE). 

The interchange of information between BASE and MOB is in 
the form of frames. There are 21 different types of 
frames. 
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2 FRAME TYPES 



There are 21 different frame types: 

Name Designation Transmitted by 
BASE MOB 



1 


M frame 


<MRM> 


Yes 


Yes 


2 


Acknowledgement 


<ACK> 


Yes 


Yes 


3 


Negative acknowledgement 


<NAK> 


Yes 


Yes 


4 


Repetition request 


<REB> 


Yes 


Yes 


5 


Repetition reply 


<RES> 


Yes 


Yes 


6 


Access request, data 


<ABD> 


No 


Yes 


7 


Access request, speech 


<ABT> 


No 


Yes 


a 


Access request, emergency 
Access permission, data 


<ABL> 


No 


Yes 


9 


<ATD> 


Yes 


No 


10 


Access permission speech 
Access permission, emergency 


<ATT> 


Yes 


No 


11 


<ATL> 


Yes 


No 


12 


Change channel, data 


<BKD> 


Yes 


No 


13 


Change channel, speech 


<BKT> 


Yes 


NO 


14 


Free signal 


<FRI> 


Yes 


... No 


15 


Sweep signal 


<SVP> 


Yes 


No 


16 


Silence order 


<TST> 


Yes 


NO 


17 


Activity request 


<AKT> 


Yes 


No 


18 


No access permission, speech 


<NAT> 


Yes 


NO 


19 


Change base station, speech 


<BBT> 


Yes 


No 


20 


Wait for channel, speech 


<VKT> 


Yes 


No 


21 


Cancel access request, speech <AAT> 


No 


Yes 
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3 DESCRIPTION OF GENERAL FIELDS 

In this chapter the general fields of a frame are 
described. Fields occuring only in specific frame types 
are described in conjunction with the definition of the 
respective frame type. 

The fields are described in the following order: 

address of mobile terminal, or group 
type of frame 

number of blocks in the frame 
check sum 

for masked addressing 
for priority addressing 
frequency number, up frequency 
frequency number, down frequency 
number of retransmissions 



1 


MOB 


2 


TYPE 


3 


BLOCK 


4 


PARITY 


5 


MASK 


6 


PRIO 


7a 


UPFREQ 


7b 


DOFREQ 



The most significant bit lies .to the left in the field, 
has the lowest order number and is sent and received first 
in time. 



01 02 03 04 05 



MOB states the address of the mobile unit concerned. 
This address refers to the terminals own 
subscription number, or to any number representing a 
group to which the terminal belongs. 
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TYPE is bit 28-32 of the primary block and indicates 
the type of frame according to the following table: 



Value 
Decimal Binary 



Type 

designation 



01 


00001 


<MRM> 


02 


00010 


<ACK> 


03 


00011 


<NAK> 


04 


00100 


<REB> 


05 


00101 


<RES> 


06 


00110 


<ABD> 


07 


. 00111 


<ABT> 


OS 


01000 


<ABL> 


09 


01001 


<ATD> 


-10 


010*0- - 


<ATT> 


11 


01011 


<ATL> 


12 ' 


. 01100 


<BKD> 


13 


01101 


<BKT> 


14 


OHIO 


<FRI> 


15 


onii 


<SVP> 


16 


10000 


<TST> 


17 


10001 


<AKT> 


18 


10010 


<NAT> 


19 


10011 


<BBT> 


20 


10100 


<VKT> 


21 


10101 


<AAT> 



States the number of blocks in the frame, including 
primary block. 



PARITY 01 02 03 . . 14 15 16 



A frame comprises one or more blocks. A block 
•comprises a source word and a coded parity word. 
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MASK 01 02 03 04 05 



A group of terminals is addressed with masked 
addressing. The MASK states the number of most 
significant bits of the MOB address that should be 
ignored. 



PRIO 01 02 03 



PRIO 


7 


111 


6 


110 


5 


101 


4 


100 


3 


011 


2 


010 


1 


001 


0 


000 



Meaning 



Priority group 4, raised priority 

, normal 

Priority group 3, raised priority 

" , normal 

Priority group 2, raised priority 

" r normal 

Priority group 1, raised priority 

. " f normal 



OPFREQ 01 02 03 04 



12 13 14 15 -16 



I <-FHI — > I < FREQ. NO. > 

DOFREQ 01 02 03 . . . 12 13 14 15 16 
1 I 1 1 1 ' ' 



States the frequency number, OPFREQ for transmit 
frequency and DOFREQ for receive frequency. 

Bit 1 to 3 gives FBI (frequency band and bit rate 
INFORMATION) and bit 4 to 16 gives the frequency 
number. Both the parameters are defined in reference 
Rl-06. 



NUMRET 01 02 03 04 05 06 07 > 



States the number of retransmissions, including the 
current try. 
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4 FRAME TYPE DESCRIPTIONS 


4.1 FRAME TYPE <MRM>, M 


-frame 



APPLICATION An <MRM> is used to transfer packets. The 
packet format is defined in reference 
Rl-09 . 



PRIMARY BLOCK 

01 02 03 



0 0 0 0 1 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 



— 1 I I ' ■ 



States the number of valid octets in the 
last following block. Remaining octets of 
the last block are filled with "0" to give 
a complete block. The field contains 6 
bits and is used in the following way: 

26 27 33 34 35 36 



SEQUENCE States the sequential number of the frame. 

RE States whether a response is to be given 

to the frame. The mobile terminal shall 
always set this flag to "1" on 
transmission. 

INFO Contains 12 octets of source data from the 

packet . 
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FOLLOWING BLOCK 








APPLICATION The packet is placed in the following 

blocks with 18 octets from the packet in 
each. The number of valid octets in the 
last following block is indicated in the 
OCTET field of the primary block. The last 
following block is filled with "0" in the 
octets which do not belong to the packet. 






01 02 03 04 05 06 


144 

i i i i i i 








INFO 








145 

i i i i i i 


160 

i i i i i i i i i 








PARITY 




- 


INFO Contains 
packet. 


18 octets of source data from 


the 
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4.2 FRAME TYPE <ACK>, Acknowledgement 


APPLICATION An <ACK> acknowledges a correctly received 


frame. 





<ACK> indicates that all blocks In the 
frame have been correctly received. It 
includes the sequential number of the 
received frame. 



PRIMARY BLOCK 



01 02 03 22 23 24 25 26 27 28 29 30 31 32 
I I 1 I 1 I I I I 1 1 1 1 1 



L .. .1, ..1 -1 — 1 1 1 

MOB 


1 1 

0 0 0 


0 0 


0 


— 1 — 

1 0 


33 34 


35 


36 


37 38 39 40 


41 42 43 

i i 


44 45 


46 


47 48 
i 


0 "0 


0 


0 


SEQUENCE 


BLOCK 


49 SO 
L 


51 

I 1 


52 


53 .54 




1 1 


..... 


. 144 


0 0 


0 


0 


0 0 


0 


0 0 


0 


0 0 


145 


1 1 






I 1 1 




1 


160 

! 



PARITY 



States the sequential number of 
the corresponding <MRM>-f rame. 



No following blocks in this type 
of frame. 
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4.3 FRAME TYPE <NAK>, Negative acknowledgement 

APPLICATION A <NAK> requests repetition of the entire 
<MRM>. 

<NAK> indicates that the primary block has 
been correctly received, but that the 
following blocks have been lost. It 
contains the sequential number of the 
received primary block. <NAK> results in a 
complete repetition of the lost <MRM>. 

Note that if the number of blocks in <MRM> 
was 3 or more, <REB> is used instead of 
<NAK>. 



PRIMARY BLOCK • 
01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



, 1 I ... ,.J .. _.L 1 1 

MOB 


0 0 0 


0 0 


0 


1 1 


33 34 


35 


36 


37 38 39 40 


41 42 43 

i • i 


44 45 

i 


46 


47 48 

i 


0 0 


0 


.0 


SEQUENCE 


BLOCK 


49 50 


51 
1 


52 


53 54 


i 






144 

I 


(__L _J 
0 0 


0 


- 

0 


0 0 


0 


0 0 


. 

0 


0 0 


145 

,„ l ... 


_J 




_ 1 — 1 1 


1 .. ,.l ., 


1 




160 



States the sequential number of 
the corresponding <MRM>-frame. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.4 FRAME TYPE <REB>, Repetition request 
APPLICATION 



A <REB> requests repetition of erronous 
blacks in an <MRM>. 

If it is found during reception that 
certain blocks in a frame cannot be 
corrected ; a request for these blocks to 
be repeated can be made by transmitting a 
<REB>. The request contains a bit map of 
the blocks to be repeated. This bit map 
refers to the original <MRM>, even during 
a sequence of repetitions. 

<REB> contains the sequential number of 
the received <MRM> primary block and 
results in a <RES>. 

Note that if the number of blocks in <MRM> 
was 2 or less, <NAK> is used instead of . 
<REB>. - 



PRIMARY BLOCK 



01 02 03 22 23 24 
1 i .!_ — I 1 1 1 


25 26 27 
i i 


28 29 30 31 32 
1 1 i 1 


MOB 


0 0 0 


0 0 1 0 0 


33 34 35 36 

iii. 


37 38 39 40 


41 42 43 44 45 46 47 48 

I 1 1.1 1 J _! 1 


0 0 0 0 


SEQUENCE 


BLOCK 



I.I — I — I — 
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the corresponding <MRM>-f rame. 

REPMAP Contains a bit map where each 

bit represents a block in the 
<MRM> previously received. A bit 
set to "1" indicates chat the 
corresponding block is to be 
repeated. The bit in a REPMAP 
representing the primary block 
shall always have the value "0", 
since repetition of the primary 
block is illegal-. 



FOLLOWING BLOCK No following blocks in this type 

of frame. 
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4.5 FRAME TYPE <RES>, Repetition reply 

APPLICATION A <RES> is the reply to a <REB>. 

<RES> is a selective repetition of blocks 
from an <MRM>. The following blocks of the 
<RES> contain copies of blocks according 
to the bit map of the <REB>. <RES> 
contains the sequential number of the 
original <MRM>. 



PRIMARY BLOCK 



01 02 03 22 23 24 25 26 27 28 29 30 31 32 
I 1 1 1 1 1 1 1 1 1 1 1 1 1 



1 — 1 — 1 — 1_ _1 — 1 — 1 — 1 

MOB 


1 1 

0 0 0 


0 0 10 1 


33 34 35 36 37 38 39 40 
1 1 1 1 1 1 1 


41 42 43 44 45 46 47 48 

i i i i i ,- i i 


0 0 0 0 SEQUENCE 


BLOCK 



49 50 51 52 53 54 , 144 

I l l 1 1 1 1 1 1 1 1 1 

0 0 0 0 0 0 0 0 o o o o 



SEQUENCE States the sequential number of the 
corresponding <MRM>-frame. 



A.JMSISW 



Exhibit 2, p. 626 



Cantel Mobitex- 



91/1056 - A. 296 5171/A2 Ue 



1990-02-22 A 



FOLLOWING BLOCK 
APPLICATION 



The following blocks contain copies of 
blocks according to the bit map of the 
<REB>. Only blocks requested to be 
repeated shall be packed into the 
following blocks. The order of the blocks 
is that stated in REPMAP. 



01 02 03 04 05 06 



144 



REPBLOCK The copy of a block from the original 
<MRM>-£rame. 
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4.6 FRAME TYPE <ABD>, Access request, data. 

APPLICATION An <ABD> is a request to transmit an <MRM> 
whose length (number of blocks) exceeds 
the value of MAX_ACCESS. 

If the length of the <HRH> exceeds 
MAX_ACCESS, access must be requested 
before the <MRM> may be sent. 

The <ABD> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



49 50 51 52 53 54 55 56 57 



-1 1 1 1 I L_ 



States the number of blocks for 
..which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.7 FRAME TYPE <ABT>, Access request, speech 

APPLICATION An <ABT> is a request to transmit an <MRM> 
containing a request for a line 
connection, whose length (number of 
blocks) exceeds the value o£ MAX_SPEECH. 

The <ABT> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



0 0 111 



49 50 51 52 53 54 55 56 57 



States the number oE blocks for 
which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.8 ERAME TYPE <ABL>, Access tequest, emergency. 

APPLICATION An <ABL> is a request to transmit an <MRM> 
containing an emergency signal whose 
length exceeds the value of MAX_ACCESS. 

If the length of the <MRM> exceeds 
MAX_ACCESS/ access must be requested 
before the <MRM> may be sent. 

The <ABL> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



1 — I — 1 — 1_ — 1 — J — 1 — 

MOB 


0 


0 0 


! 

0 1 


I 

0 


., 1 
0 0 


33 34 35 36 37 38 


39 40 

i 


41 


42 4.3 


44 45 


46 


47 48 


BLOCK N 


BLOCK 


49 50 51 52 53 54 
ii i i i 


55 56 

i 


57 




_J 


, 


144 

1., ., 


NUMRET 


0 






0 


0 0 


145 

i i i i i 




1 1 




I 


_i 


160 



States the number of blocks for 
which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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1990- 


I*. 

02-22 A 


1 MTS16A.2 • 




4.9 FRAME TYPE <ATD> , Access permission, data. 




APPLICATION BASE replies with an <ATD> to an <ABD> 

from a MOB, when BASE is ready to accept 
an <MRM>. 




When permission is granted, MOB is 
expected to transmit an <MRM> containing a 
data packet. 


PRIMARY BLOCK 












01 02 03 22 


23 24 


25 26 27 


28 29 30 31 32 






MOB 


0 0 0 


0 10 0 1 






33 34 35 36 37 38 

1 1 1 | I L 


39 40 


41 42 43 


44 45 46 47 48 






0 0 0 0 0 0 


0 0 


BLOCK 






49 50 51 52 53 54 
■ ' ' 1 1 1 






144 

l_J 1 1 1 






0 0 0 0 0 0 




0 


0 0 0 0 0 






145 

i i i i i i 






160 






PARITY 





No following blocks in this type 
of frame. 
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4.10 FRAME TYPE <ATT>, Access permission, speech. 

APPLICATION BASE replies with an <ATT> to an <ABT> 

from a HOB, when BASE is ready to accept 
an <MRM>. 

When permission is granted, MOB is 
expected to transmit an <MRM> containing a 
request for line connection. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



1 1 L— _U 1... 1, 

MOB 


1 I 

0 0 0 


0 1 


1 1 

0 10 


33 34 


3S 36 37 
' » 


38 39 40 


41 42 43 


44 45 
i 


46 47 48 

i r 


0 0 


0 " o "~o 


0 0 0 


BLOCK 


49 50 
1— J 


51 52 53 
i • 


54 






. 144 


0 0 


0 0 0 


0 


0 


0 0 


1 

0 0 0 


145 

i 


1 1 


1 1 







160 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.11 FRAME TYPE <ATL> , Access permission, emergency. 

APPLICATION BASE replies with an <ATL> to an <ABL> 

from a MOB, when BASE is ready to accept 
an <MRM>. 

When permission is granted, HOB is 
expected to transmit an <MRM> containing 
an emergency signal. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



0 10 1 1 



33 34 35 36 37 38 39 40 41 42 43 



45 46 47 48 



0 0 0 0 0 0 0 



49 50 51 52 53 54 
I ' ' ' I L 

0 0 0 0 0 0 



. 1 1 1 L_ 



0 0 0 0 0 0 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.12 FRAME TYPE <BKD>, Change channel, data- 
APPLICATION 



A <BKD> orders a MOB to another channel in 
order to transmit or receive an <MRM>. 

The MOB usually returns to the original 
channel when the <MRM> has been 
transmitted or received. If an error 
occurs on the assigned channel then MOB 
returns to the original channel after a 
timeout period stated in the <BKD>. 



PRIMARY BLOCK 



01 02 03 


22 


23 


24 


25 


26 


27 


28 29 


30 


31 


32 


MOB 


0 


0 


0 


0 1 


1 


0 


0 


33." 34 35 36 37 
_l ..1... 1 1 .. 


38 


39 


40 


41 


42 


43 


44 45 


46 


47 


48 


0 0 0 □ 0 


0 


0 


0 


BLOCK 



49 64 65 

BKDFL 



97 

f TIMEOUT 



OPFREQ 



)FRE Q ' | 



DOFREQ 



0 0 0 0 0 
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Indicates how the terminal is to act on 
the new channel. 

1 . Reserved 

2 Reserved 

3 Reserved 

4 Change to send <MRM> 

5 Change to receive <MRM> 
6.. 16 Reserved 



Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number of down frequency, i.e 
the frequency on which BASE transmits. 

If error, return after TIMEOUT seconds 
(1-255). 



FOLLOWING .BLOCK 



No following blocks in this type 
of frame. 
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4.13 FRAME TYPE <BKT>, Change channel, speech. 

APPLICATION A <BKT> orders a MOB to another channel in 
order to transmit or receive an <MRM> 
containing a request for line connection. 

Normally the terminal returns to the 
original channel when the line connection 
is over. If an error occurs on the 
assigned channel then. MOB returns to the 
original channel after a timeout period 
stated in the <BKT>. . 



PRIMARY BLOCK 

01 02 03 22 23 24 25 25 27 28 29 30 31 32 



L l.,__L^_l 1 1 1 

MOB 


0 0 0 


0 110 1 


33 34 35 36 
1 ! ._! 


37 38 39 40 


41 42 43 44 45 46 47 48 


0 0 0 0 


SEQUENCE 


1 ' • ' ' ' ' ' ' 1 
BLOCK 



49 64 65 

BKTFL 



| BKTFI 
97 

| TIMEOI 



0.0 0 0 0 



145 160 
I 1 I I I 1 1 1 1 L 1 1 1 1 " 1 1 
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SEQUENCE Only valid if BKTFL bit 6 is TRUE. 



• Indicates how the terminal is to act on 
the new channel. 

Bit 1 - Reserved 

2 Reserved 

3 Reserved 

4 Change to send <MRM> 

5 Change to receive <MRM> 

6 Acknowledgement, (including sequence 
number) of correctly received speech 
<MRM>. Ignore timeout. 

7 . . 16 Reserved 



UPPREQ ■ Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

DOPREQ Frequency number of down frequency, i.e. 

the frequency on which BASE transmits. 

TIMEOUT If error, return after TIMEOUT seconds 
d-255). 



FOLLOWING BLOCK 
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4.14 FRAME TYPE <FRI>, Free signal 
APPLICATION 



BASE transmits a <FRl> when it is ready to 
handle traffic from MOB. 

A free signal precedes a free cycle. A 
free cycle is a period of time when all 
of., or parts of, the total fleet of mobile 
terminals are collectively permitted to 
transmit. 



PRIMARY BLOCK . 



22 23 24 25 26 27 28 29 30 31 32 



0 1110 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 



49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 



RAND SLOTS 



65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 



MAX ACCESS 



SLOT LENGTH 



81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 



MAX SPEECH 



00000000 



0 0 0 0 0 0 



I I I ! 1 1 — 
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FFG The FFG field states the type of traffic 

to which the free signal applies according 
to the following table. 


Value Emergency Sneech Data 


00 
01 
10 
11 


yes no no 
yes no yes 
yes yes no 
yes yes yes 


RAND_SLOTS 


The maximum, number of the random 
number generator which selects 
in which slot. the transmission 
shall start. 


FREE_SLOTS 


The number of free slots in this 
free cycle. 


MAX_ACCESS 


States the number of blocks 
which may be sent in an <MHM> 
without being preceeded by an 
access request. 


SLOT_LENGTH . 


Current value of slot_length. 


MAX_SFEECH 


States the -number of blocks 
which- may be sent in a line 
connection request without being 
preceeded by an access request. 


FOLLOWING BLOCK 


No following blocks in this type 
of frame. 
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4.15 FRAME TYPE <SVP>, Sweep signal 

APPLICATION The sweep signal is a periodically 

recurring signal from BASE. An <SVP> is 
transmitted by BASE for two reasons: 

1 <SVP> marks the start of a swe< 
cycle. 

2 <SVP> contains system 
parameters. 

<SVP> has 2 different subtypes: 

1 states the values of system 

parameters 

• 2 states the frequency of 

different channel types 
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- states the values of system 
parameters. 



PRIMARY BLOCK 

. 01 02 03 22 23 24 25 26 27 28 29 30 31 32 



0 1111 



33 34 35 36 37 38 39 40 


41 42 43 44 45 46 47 48 


1 1 j 1 1 1 1 

PRIO MASK 


BLOCK 


49 50 51 52 53 54 55 56 


57 58 59 60 61 62 63 64 

I I 1 1.1 1 . _! 1 


SVPTYP 


TXPOW 


65 66 67 68 69 70 71 72 
1 1 1 1 1 1 1 


73 74 75 76 77 78 79 80 
I i 1 1 1 ! 1 1 


RSSI PROC 


RSSI PERIOD 


81 82 83 84 85 86 87 88 
__i 1 1 1 1 1 1 


89 90 91 92 93 94 95 96 
I, 1 1 1 1 1 1 1 


TIME TO NEXT 


" MAX REP 


97 104 
1 1 1 1 1 1 1 


105 112 

' ' ' • ' i i- J— —J 


BASEST 


SCAN_TIME 


113 120 


121 128 
i i i i i i i 


BAD BASE 


GOOD_BASE 


129 136 
1 I I I 1 1 1 


137 144 
■ i i i i i i 


BETTER BASE 


00000000 


145 160 
1 1 1 1 1 1 1 1 1 1 1 1 1 " 1 


PARITY 
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SVPTYP 


States the <SVP> subtype, value 
00000001 in this case. 


TXPOW 


States the decrease in output 
power (0—255 dB below nominal 
level) to be used by the mobile. 
A default value of 0 is used 
until this signal is received. 


RSSI_PROC 


States, the method of the signal . 
strength measurement: 

0 = FRAME 

1 = CONTINUOUS 

The default value is FRAME. 


RSSI_PERIOD 


Time used by the roaming 
algorithm (0-255 *20 ms) . 
Default value: 148 (2 960 ras). 


TIHE_TO_liEXT_. 


States the time in seconds to 
the next <SV?> frame. 
Default value: 10. 


MAX REP 
BASEST 


States the value of the variable 
Max_rep. 

States status of base station. 


SCAN_TIME 


States the length of a period 
(0-255 *100 ms) when the 
terminal scans other system 
channels . 

Default value. 30 (3 seconds) • 


BAD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 


GCX)D_BASE 


Used by the roaming algorithm. 
0-255 .dBuV. Default value: 15. 


BETTEH_BASE 


Used by the roaming algorithm. 
0-255 dB. Default value: 10. 


Most of the parameters above are further described in the 
MAIN DOCUMENT. 
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FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 



If any, they contain a list of 
system channels to be used in 
base station monitoring. A frame 
with a list containing new 
system channels completely 
overrides the previous frame. 
The channel list has the 
following format (as described 
in the MAIN DOCUMENT) : 



01 02 03 04 05 06 07 08 
III I.-.J -J 


09 10 11 12 13 

1 1—1 L_ _.!„.,_ 


14 15 16 
1 1 


number of channels 


0 0 0 0 0 


0 0 0 


17 32 


33 


48 

1 1 


channel #1 - UPFREQ 


channel #1 - 


DOFREQ 


49 64 


65 


80 

I I 


| 1 .... I 1— .- 

. channel #2 - UPFREQ 


channel #2 - 


DOFREQ 


81 96 
,,11 1, 1 


97 


.112 
_l_ .1 — J 


channel #3 - UPFREQ 


channel S3 - 


DOFREQ 


113 128 


129 


144 
.... _J... _l 


channel #4 - OPFREQ 


channel #4 — 


DOFREQ 


145 

l I l I l l l 


1.1 1 1 


160 



The number of following blocks depends on the size of the 
list. The maximum number of channels in the list is stated 
in reference Rl-06. 

Continues with following block #2 on the next page. 
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FOLLOWING BLOCK #2 
01 



— I 1 - 



— 1 — 1 — 

DPFREQ 


channel #5 - 


I I 
DOFREQ 


48 

1 i 


49 


64 

1 1 


DPFREQ 


channel #6 - 


DOFREQ 


144 

1 1 


145 


160 


UPFREQ 


PARITY . 



- FOLLOWING BLOCK #3 



channel #9 - DOFREQ 



channel #10 - DPFREQ 



33 48 
1 1 L . 1 1 ! 


49 64 


channel #10 - DOFREQ 


channel #11 - DPFREQ 
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<SVP>, SUBTYPE 2 
PRIMARY BLOCK 



• states the frequency of 
. different channel types. 



0 1111 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 - 



1 1 

PRIO 


i 1 1 i 

MASK 


BLOCK 


49 50 51 


52 53 54 55 56 


57 


58 59 60 61 


62 


63 64 
i 


SVPTYP 


CHATYP 


65-66 67 
i i 


68 69 70 71 72 


73 


74 75 76 77 


78 


79-80 


OPFREQ 


81 82 83 

i i 


84 85 86 87 88 
iiii 


89 


90 91 92 93 

i i i 


94 


95 96 


DOFHEQ 


97 98 99 
1 1 1 1 


100 




. i .1 . J_ .. 




144 


0 0 0 


0 0 0 




0 0 0 


0 


0 0 
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States the <SVP> subtype, value 00000010 
in this case. 

States the type of channel: 
Value: 

1 Local system channel opened 

2 Not used (ignore that order) 

3 Local system channel closed 
(return to national system 
channel ) 

4 Access channel opened 

5 Access channel closed 

Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number for down frequency, i.e. 
the frequency on which BASE transmits. 



FOLLOWING. BLOCK 



No following blocks in this type 
of frame. 
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4.16 FRAME TYPE <TST>, Silence order 

APPLICATION Silence order is used by BASE to withdraw 
all access permissions during a free 
cycle- A MOB that is already transmitting 
may continue to do so, but for every other 
MOB the access permissions for all traffic 
types { emergency t speech and data) are 
withdrawn. 

Note: Please also refer to the description 
of the silence signal in reference 
Rl-17. This signal has the same 
meaning as the <TST>-frame but uses 
only the frame head and thus 
addresses ALL mobile terminals. 



PRIMARY BLOCK 



.1... L__l_ _1 1 1 

MOB 


1 1 1 1 1 1 1 

00010000 


33 34 35 36 37 38 39 40 
l 1 1— J 1 1 1 


41 42 43 44 45 46 47 48 


PRIO MASK 


BLOCK 



49 50 51 52 53 54 144 
1 I I 1—1 1 1 1 1 1 1 1 

oooooo oooooo 



PARITY 



No following blocks in this type 
of frame. 



AiS3 51S3.3 
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4.17 FRAME TYPE <AKT>, Activity request 

APPLICATION An <AKT> is used by BASE to check whether 
a aertain MOB is active. MOB replies with 
an <ACK> to such a £rame. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



1 1 1 L_ _l 1 1 1 

MOB 


0 0 


■o 


1 0 


0 


0 1 


33 34 
1 1 


35 36 37 
' I 1 


38 39 40 


41 42 


43 


44 45 


46 


47 48 

1 


0 0 


poo 


0 0 0 


BLOCK 


49 50 

,„ 1,;-, 


5152 53 


54 

- ...It- - 










144 


0 0 


0 0 0 


0 




0 


0 0 


0 


0 0 


145 










i 




160 


PARITY 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.18 FRAME TYPE <NAT>, No access permission, speech 

APPLICATION BASE replies with <NAT> to an <ABT> or a 
line connection request from a MOB when, 
for some reason, a line connection cannot 
be set up (e.g. no channel is available). 



PRIMARY BLOCK 

01 02 03 



J 1 1 1 1 



22 23 24 25 26 27 28 29 30 31 32 



10 0 10 



33 34 35 36 37 38 39 40 41 42 43 < 44 > 45 ^ 46 < 47 



000000 00 



49 50 51 52 53 54 55 56 57 



NATFL 
Bit 49 

50 - 56 



Contains the following orders: 
Leave CORRENT_BASE . 
Reserved 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.19 FRAME TYPE <BBT>, Change base station/ speech. 

APPLICATION BASE will use <BBT> 

- as a response to an <ABT> when another 
base station is to be used for the line 
connection 

or 

- to hand over a call in progress to 
another base station. 

PRIMARY BLOCK 

01 02 03 22 23 24 25 26 27 23 29 30 31 32 



1 1 1 _1 — 1 — 1 — 

MOB 


1 1 1 

0 0 0 


1 0 


_l 
0 


1 1 

1 1 


33 34 


35 


36 37 38 39 40 


41 42 43 


44 45 


46 


47 48 


1 1 " 


TIMEOUT _ 


BLOCK 


49 50 


51 


52 53 54 55 56 

■ i i i 


57 58 59 


60 61 


62 


63 64 
. I .J 


BBTFL 


65 66 


67 


68 69 70 71 72 

■ i i i 


73 74-75 


76 77 
i 


78 


79 80 


SPEECH DPFREQ 


81 82 


83 


84 85 86 87 88 


89 90 91 


92 93 


94 


95 96 


SPEECH DOFREQ 


97 98 


99 


100 




i 




112 
1 


BASE 


113 




■ i t i 


i i 






128 


NEW SYSTEM UPFREQ 


129 












144 

I I 


NEW SYSTEM DOFREQ 


145 






i i i 


i i 


1 , . 


160 
J 1 


PARITY 
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Bit 49 
50 



52 



If error, return after TIMEOUT seconds 
(1-255). 

Indicates the terminal is to act after 
changing to the new base station. 

Reserved 
Reserved 

After the call, use BASE as new current 
base station. 

After the call, return to old current 



53 Change and start the call set_up procedure 
from the beginning (new <ABT> on BASE). 

54 Change and continue (either signalling 
procedure or call in progress). 

55-64 Reserved 



BASE 
SPEECH OPFREQ 
SPEECH DOFREQ 
NEW SYSTEM tJBFHEQ 

NEW SYSTEM DOFREQ 



FOLLOWING BLOCK 



t base station to be 



Frequency number for 
transmitting speech. 

Frequency number for receiving 
speech. 

Frequency number for upwards 
traffic on 'the new system 
channel, i.e. the frequency on 
which the terminal transmits. 

Frequency number for downwards 
traffic on the new system 
channel, i.e. the frequency on 
which the terminal receives. 



No following blocks in this type 
of frame. 



This order is only valid if both BBTFL 3 and BBTFL 6 are 
raised, i.e. hand over of a call in progress. 

Other combinations of BBTFL are to be included in later 
versions. 
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4.20 FRAME TYPE <VKT>, Wait for channel, speech 

APPLICATION BASE replies with one (or more) <VKT>- 
frame(s) to an <ABT> from a MOB when a 
speech channel is not immediately 
available. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



MOB 


.. 1 
0 0 


L 

0 


, ,1 , 
1 0 


1 


1 ! 1 

0 0 


33 34 


35 36 37 


38 


39 40 


41 42 


43 


44 45 
i 


46 


47 48 
i 


|_ L.„. 

0 0 


0 0 0 


0 


0 0 


BLOCK 


49 50 


51 52 53 


54 


55 56 


57 58 


59 


60 61 
i 


62 


63 64 
i 


TIMEOUT 


QPOS 


65 66 
L L 


67 68 69 
1 1. ..J 


70 






I 






144 


0 0 


0 0 0 


0 






• 0 


0 0 


0 


0 0 


145 
1 


I 1 1 t 










1 





160 



If the mobile terminal has not received a 
<BKT> or a <NAT> within TIMEOUT seconds 
(0-255), the <VKT> is invalidated. 

States current position (1-255) in queue. 
It is recommended that this parameter is 
passed on to the application layer and 
shown to the operator. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.21 FRAME TYPE <AAT>, Cancel access request, speech 

APPLICATION HOB transmits an <AAT> when it wants to 

end a call and has been placed in a queue 
by BASE. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



1 1 1 III. 

MOB 


0 


-L 

0 0 


. J 
1 0 


1 


0 1 


33 34 


35 


36 37 38 39 


40 


41 


42 43 


44 45 
1 1 


45 


47 48 


0 0 


"0 


0 0 0 0 


0 


BLOCK 


49 50 

.. I 


51 

1 1 


52 53 54^55 


56 


57 






1 1 


144 


0 0 


0 


0 0 0 0 


0 


0 






0 


•0 0 


145 




1 1 — 1 — 1 — - 




1 


1 1 




- 


160 
1 I 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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5 CONVERTING A PACKET TO A FRAME 



<MRM>-fraraes conveys MPAKs ovar the radio channel. The 
primary block can accomodate 12 and each following block 
18 octets from the MPAK. 



HOB address 
Control field 



Parity field 



Next . 18 _ .. 
octets of MPAK 



Parity field 



iry b: 
with link layer 
information 



Following 
block #1 • 



Following 
block #n 



When converting a packet to a frame, the first 12 octets 
in the' packet shall be placed in the primary block of the 
frame. The last octets of the packet are placed in the 
last block. The primary block indicates how many octets in 
the last following block that are used. Unused octets in 
the last following block are filled with octets containing. 



In the primary block of the <MRM>-frame the Link Layer 
information is added. The MOB address field of the primary 
block shall always contain the MAN of the physical 
terminal concerned or, when the base station is 
transmitting to a group, the MAN of the addressed group. 
The base station identity is contained in the frame head 
preceding the primary block. 

The addresses in the MPAK itself indicates the sub- 
scriptions concerned (terminal, transferable or group). 
For packets to/from the terminal itself or its group 
numbers, the MOB address field of the primary block and 
the address in the MPAK are the same. For packets to/from 
a transferred subscription, the corresponding addresses 
differ. 
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6 BLOCK CODING 



6.1 GENERAL DESCRIPTION 

The code used is a cyclic block code for burst error 
control. The code message consists of 144 source data bits 
and a block check character [CRC, i.e. parity) of 16 bits, 
giving a total of 160 bits in a block. 

The generator polynomial defining the code is 

g(X) = X 16 + X 12 + X 5 +1 

i.e. CRC-CCITT X.25. 

The CHC is initialized to all ones, calculated from all 
the 144 source-data bits of the block and then its one's 
complement is transmitted. 

This code detects all (single) error bursts up to 16 bits 
in length and about 99,998% of all other error patterns. 



6.2 IMPLEMENTATION 

CRC calculations are customarily done in a multi-section 
shift register which feeds into an exclusive-OR gate whose 
output feeds back to other XOR gates located in between 
the sections of the shift register. The placement and 
quantity of XOR gates are defined by the generator 
polynomial. 

The CRC is then transmitted after the source data of the 
block. 

A logical arrangement identical to that used in the 
transmitter is also used in the receiver. Again the CRC- 
register is initialized to all ones, the CRC is calculated 
from the 144 source bits and its one's complement is 
compared to the received CRC. If thes are different an 
error has been detected. 

Instead of hardware logic a software algorithm may be 
used. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Rl-06, 7, 
Rl-09, 8 
Rl-17, 35 



31 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

- — General description of terminals — 

Rl-04 Terminology 

Rl-05. References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-U Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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ABSTRACT 

This document specifies the Physical Layer for mobile 
terminals connected to the MOBITEX network. 

The exchange of information between base radio station and 
mobile is done - by frames. A frame consists 'of a frame head 
and blocks. 

The frame head is added to the message sent by the Data 
Link Layer to establish synchronisation and identify the 
base station. It also includes a set of control flags. 

The blocks in a frame contain the data to/from the Data 
Link Layer plus parity bits - for error correction. 
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The protocol in the Physical Layer describes the way the 
mobile terminal handles the radio channel. The logical 
structure of the protocol is described in this document, 
while hardware-related functions such as: 

method of modulation 

suitable equipment for implementation 

requirements for the equipment 

are presented in reference Rl-18. 



Exhibit 2, p. 660 



Cante! Mobitex- 



10/1056 - A 296 5171/02 Ue 



1990-02-26 A 



2 THE CHANNEL 



2.1 GENERAL CHARACTERISTICS 

The channel between the base radio station and the mobile 
terminal uses 

separate frequencies for transmission and reception, 
synchronous communication and 
frequency modulation (FM). 
It. is also affected by 

varying .field-strength, 

random errors and burst errors caused by fading and 
noise and -- - 

bit errors caused by ignition interference. 

Consideration has been given to these and other factors in 
the design of the protocol for the Physical Layer. 



2.2 FRAME STRUCTURE ' ' 

The exchange of information between base station and 
mobile is done by frames. A frame has the following 
structure: 



| Frame head | Block #1 | Block #2 | _ | Block ftn" 



The frame head is a very important part of the frame. It 
is added to the message sent by the Data Link Layer to 
establish synchronisation and identify the base radio 
station. 

The blocks in a frame contain the data to/from the Data 
Link Layer plus parity bits for error correction. 

When the number of blocks is zero, i.e. when only a frame 
head is sent, the term "signal" is used. 
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3 THE FRAME HEAD 



3 . 1 STRUCTURE 

The frame head has the following structure: 
01 02 03 04 05 06 07 08 09 .10 11 12 13 14 15 16 



1 1 1 1 1 1 1 1 1 1 1 L- ! 1 1 

BIT SYNCHRONISATION 


17 18 19 20 21 22 


23 24 25 26 27 28 


29 30 


31 32 


FRAME SYNCHRONISATION 


33 34 35 36 37 38 
-,. 1, I.. .J 1 


39 40.A1 42 43 44 


45 46 


47 48 


BASE IDENTITY 


j__J L 1. ..._J 1 

AREA IDENTITY ■ 


CTRL 


FLAGS 


49 50 51 52 53 54 
1 1 ,..,_!._.. 1 ,!_.,. 


55 56 
1 







PARITY BITS 



The different parts of the frame head are described in the 
following chapters. 
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3.2 SYNCHRONISATION 



3.2.1 Bit synchronisation 

This preamble is provided to enable bit sychronisation in 
the demodulator. It consists of 16 bits with the following 
pattern (bit #1 is. sent first): 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 



10 0 11 



1100 1100 



1100110011 0 0 1 1 



from BASE 
from MOB 



3.2.2 Frame- synchronisation 

The frame synchronisation is provided to establish correct 
code word f raming. Each, network has its own pattern, used 
as network identification number, defined in reference Rl- 
06. In order to roam into base radio stations in other 
networks, it should be possible to manually change the 
frame synchronisation word from the application layer. 

It consists of 16 bits with the following structure, with 
bit #1 sent first: 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 



xxxxxxxxx 



XXXXXXXXXX X X X X X X 



from BASE 
from MOB 



If there is more than 1 bit error in the detected pattern, 
then frame sync is not established. 

NOTE Only these 16 bits are used for frame 
synchronisation. 



Exhibit 2, p. 663 



Cantel Mobitex~ 


TTTi 1 1 

10/1056 - A 296 5171/02 Ue 


1990-02-26 A | MTS17.2 



3.3 AREA IDENTITY, BASE IDENTITY AND CONTROL FLAGS 

The base identity (6 bits) and the area identity (6 bits) 
together, states the unique identity of the base radio 
station concerned. The most significant bit (01) in the 
addresses is sent first.. 

The base identity is followed by four control flags. They 
'are only used in traffic from BASE to MOB. The control 
flags are as follows (in order of reception): 



1 SA_flag 



Reserved for future use. 



2 Set_slot flag 0 = FALSE 

~ 1 = TRUE, reset slot clock. 

3 Roaming flag- 0 = FALSE 

~ 1 = TRUE, this is a roaming signal, i.e. 

it contains only a frame head. 

4 SilenceTflag" 0 « FALSE 

~ 1 = TRUE, this is a ..silence signal, i.e. 

it contains only a frame head.. 



BASE IDENTITY 



AREA IDENTITY 



CTRL FLAGS 



parity #2 , 



17 18 19 20 21 22 23 24 



The 8 (2*4) parity bits that follow the control flags are 
encoded in the same way as the blocks of the frame. Parity 
#1 is coded from octet #1 {see figure above) and parity #2 
from octet #2. 



The code corrects all single errors. In case- the frame 
head could not be corrected, it should be rejected. 

The parity bits may be ignored and the base identity and 
control flags read without any decoding. 
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4 ERROR CORRECTION AND DETECTION 



4.1 CODING 



Each block to/from the Data Link Layer contains 20 octets 
of information. These are put into a matrix of the 
following format: 



column — 1 2 3 4 5 6 7 8 9 10 11 12 . 



row 1 


octet 


#1 


parity 


2 


octet 


#2 








...... 


20. 


octet 


#20 





To each octet (column 1-3) four parity bits are added in 
the same row (9-12). These are encoded by a shortened 
(12,8) Hamming code. 

The code corrects all single errors with hard decision 
decoding . 



The code is defined by the following H-matrix: 
■ 11101100 1000 " 
11010011 0100 
10111010 0010 
01110101 0001 . 



The syndrome (s) is calculated from the received code word 
(v) by 



where H T denotes the transposed H-matrix. 
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The syndrome of a code word with a single error is equal 
to the columnvector of the H-matrix corresponding to the 
position of this error. The syndrome table is shown below. 



syndrome 


corresponds to 
a single error 
in bit position 


0 
1 


0000 0000 0001 


2 


0000 0000 0010 


3 
4 


0000 0000 0100 


5 


0000 0001 0000 


6 


0000 0010 0000 


7 


0001 0000 0000 


8 


oooo- 0000 1000 


9 


0000 0100 0000 


10 


0000 1000 0000 


' -11 - 


0010 0000 0000 


12 




13 


0100 0000 0000 


14 


1000 0000 0000 


15 





If the syndrome is 0 the code word is correct. 



The following examples illustrate the coding/decoding 
procedure: 



transmitted 
info parity 



1 0000 


0001 


0101 1 




1 0000 


0101 


1100 1 




| 0000 


0010 


0110 | 




| 0000 


0101 


1100 1 



received 

info parity 



0000 0001 0101 



0101 0101 1100 



0010 0010 0110 



0000 1111 1100 
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4.2 INTERLEAVING AND SCRAMBLING 

Before transmission the code is interleaved to give 
protection against burst errors. The block-matrix is sent 
columnwise with start at position (1,1) and is received in 
the same way. 

column — 1 2 3 4 5 6 7 8 9 10 11 12 



octet #1 


parity 


octet n 




• 




octet #20 





The., code .without interleaving can correct single errors.. 
The interleaved code can thus correct a burst of 20 
errors, assuming that there is no other error in the same 
block. 



Scrambling 

At transmission and reception the bits following the frame 
head should be added modulo-2 (exclusive-ored) with the 
output from the ninth stage of a binary nine-stage shift 
register. 

The outputs of the fifth and ninth stage of the shift 
register should be added modulo-2 and the result fed back 
to the input of the first stage. 

All bits in the shift register should be sent to the 
logical value 1 upon initialization for reception or 
transmission. 

That is, the bit3 following the frame head will be - 
exclusive-ored with the sequence: 

111111111000001111011111000101 , etc. 

This scrambling sequence is the recomended test sequence 
described in CCITT recommendation V.52 r as well as the 
shift register on the next page. 



Note: It should be possible, via a test command in MASC 
(reference Rl-19 ), to order the mobile to ■ 
start/stop sending the above described scrambling 
sequence. This should only be possible during test, 
not during normal operation. 
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Shift register stages during pseudo-random pattern 
generation. 




1 
1 


2 


3 


4 


I 

5 


6 


7 


a 


9 


Out 




1 


1 


1 


1 


1 


1 


1 


l 


1 


1 


0 


1 


1 


1 


1 


1 


1 


l 


1 


1 


0 


0 


1 


1 


1 


1 


1 


l 


1 


1 


0 


0 


0 


1 


1 


1 


1 


l 


1 


1 


0 


0 


0 


0 


1 


1 


1 


l 


' 1 


1 


0 


0 


0 


0 


0 


1 


1 


i 


1 ' 


1 




0 


0 


0 


0 


0 


1- - 


l 


1 


1 


1 


1 


0 


0 


0 


0 


0 


l 


1 


1 


1 


1 


1 


0 


0 


0 


0 


0 


1 


1 


1 


1 


1 


1 


0 


0 


0 


0 


0 


0 


0 


1 


1 


L 


1 


0 


0 


0 


0 


' 0 


1 


0 


1 


1 


1 


1 


0 


0 


0 


0 


1 


1 


0 


1 


1 


1 


1 


0 


0 


0 


1 


1 


1 


0 


1 


1 


1 


1 


0 


0 


1 


1 


1 


1 


0 


1 


1 


1 


1 


1 
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5 TIME DIVISION 



The time axis is divided into slots. The length (L) of one 
of these slots. is given by the parameter Slot_length. 



[slot n I slot n+1 [slot n+2 jslot n+3 | _ 

.+ + _ — + h + > t ime 

t t+L t+21. t+3L t+4L 



The mobile keeps a clack going to be able to detect slot 
boundaries. The start (tl) of the first slot in a sequence 
is defined by BASE transmitting a frame head with a 
Set_slot_flag»- 



[frame head) block #1 | 

to tl = to + 20 ms 



The first bit of the frame head is received at time to. 
Slot number n starts at: 

t= tl + (n-l)*L 

where 

L = .Slot_length * (32/bitrate) seconds 
n = l..x 



The tolerance for determining the start of a slot is 
-0.1/+3 ms. 
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6 TRANSMISSION 



When an order to transmit a frame (FRAME_TO_SEND) has come 
from the Data Link Layer, the Physical Layer first waits 
until the slot clock reaches the CH0SEN_SL0T (please also 
refer to chapter 8) before it: 

indicates SLOT_REACHED to the Data Link Layer 
switches the carrier on 

waits until carrier frequency and power has 
stabilized 

waits 5 ms (tolerance -OAS ms) 

sends frame head with base and area identity (from 
Current_base) and all control flags = 0 (i.e. FALSE) 
encodes and sends all blocks of the frame 



before it switches the carrier off and indicates 
FRAME_SENT to the Data Link Layer. If the order 
CANNOT SEND comes from the Data Link Layer before the 
CHOSEN_SLOT is reached, then the transmission will not be 
started. 
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7 RECEPTION 



The following takes place when correct bit and frame 
synchronisation has' been established: 

get average signal strength during reception of 

frame head *) 
send Received base to Data Link La yer 
IP received Ease = Current_base THEN 

IP Silence_flag THEN 

send Silence to Data Link Layer 



REPEAT 

read block 
decode block 

send Received block to Data. Link Layer . 
UNTIL Sync_search 



On reception of the order Measure_RSSI from the Data Link 
Layer, the average signal strength *) is measured during 
the time stated in the order. Thereafter an answer, 
RSSIjneasured, is sent to the Data Link Layer. 



*) The RSSI should be sampled with a frequency of 1000 
samples per second. 
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8 INTERFACE TO THE DATA LINK LAYER 



Parameters received from the Data Link Layer: 



Slot_length 

Chosen_slot 

Current_base 

Frame_to_serid 

Frame_length 
Sync_sear.ch 

Cannot_send 

Measure RSSI 



- states the length of a single slot. The 
unit is (32/bitrate) seconds. 

- states the slot where transmission 
starts. 

- states which base radio station is 
currently used (base and area identity). 

- is a message consisting of at least one 
block. 

- states the number of blocks in message. 



reading and enter sync search i 

- orders the Physical Layer not to send in 
any slot. 

- orders the Physical Layer to measure the 
' average received signal strength, during 

the time stated in the order. 



Parameters sent to the Data Link Layer: 



Frame_sent 

Received_block 
Received base 



Slot_reached 
RSSI Measured 



- indicates that a frame transmission is 
completed . 

- is a decoded block (w error indication). 

- states the base identity, area identity 
and the received signal strength in 
dBuV. 

- indicates that we have received a 
silence signal. 

- indicates the start of the Chosen_slot. 

- the average received signal strength, 
during in order Measure_RSSI stated 
time. 
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9 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 
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Rl-18, 3 
Rl-19, 10 
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Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 ..-™— General description of terminals 
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Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 
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Rl-11 interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile. terminals' 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



Exhibit 2, p. 673 



18 



Exhibit 2, p. 674 



REQUIREMENT SPECIFICATION 1(21) 



ET/UC SIS 


'et/dc sis" 


■snz. » — i 1 

1056 - A 296 5173/04 De 


ET/SYSC STT v £^ 


1990-02-25 A | MTS18.2 


Cantel Mobitex- 


MOBITEX 

Mobile radio equipment 
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ABSTRACT 



This document specifies the requirements for the radio 
transmitter and receiver in the MOBITEX MOBILE TERMINAL. 

The document contains a functional description and a 
detailed specification of the technical requirements and 
performance .of the transmitter and receiver. 

The equipment specified in this document . should also meet 
with basic requirements set up in national regulations for 
radio transmitters and radio receivers. 

Environmental, power supply and operational control 
requirements are found in the document General 
Requirements for the Mobile Terminal. 
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1 INTRODUCTION 



1.1 GENERAL 

The radio transceiver serves as interface between the 
. radio path and the logic and control unit of the mobile 
. terminal. Data and voice transmission is provided. 

The transmission mode is semi-duplex, the base station 
operates in full duplex mode and the mobile station in two 
frequency simplex mode. 

Digital FM modulation is used for data transmission at a 
speed of 8 kbit/s. 

The channel spacing is 12.5 kHz. 
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2 FUNCTIONAL DESCRIPTION 



2.1 DATA TRANSMISSION 

The main traffic in the Mobitex network will be of the 
data transmission type. 

A modulation type which makes it possible to utilize the 
radio transceiver for speech transmission as well as for 
data transmission has been chosen. 

The modulation type is binary digital baseband filtered PH 
at a speed of 8 kbit/s. 

There should be no squelch function during data 
transmissions.. 



The data transmission mode is used for - transmission of 
system information, system orders and for the signalling 
between the base station and the mobile station as well as 
for the user data and text transmissions. 

The data transmission mode is basically a simplex mode, 
data transmission takes place only in* one direction at a 
time. Short switchover times are important as this will 
increase the system efficiency. 
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2.2 SPEECH TRANSMISSION 

The speech transmission mode is only reached after a 
request from either a mobile or a fixed terminal. 

After a request for speech communication the base station 
allocates a radio channel and sends an order "to the mobile 
station to switch over to that channel (separate, transmit 
and receive frequencies). 

No squelch function is to be used during speech 
communication. 

The muting of the audio paths is released during speech 
communication. If, however, a data signal is detected 
during the speech, the audio paths to be muted 
immediately. This will for example occur when a data 
message is received during ongoing speech conversation. 



2.3 TRANSMITTER CONTROL 
2.3.1 Frequency 

The transmitter frequency is controlled by the control 
unit. 

For information about frequency band and channel numbering 
plan to be used, please refer to document Rl-06. 



2.3.2 Carrier 

The carrier on/off condition is controlled by the control 
unit during data transmissions. During speech transmission 
the carrier on/off condition is controlled by the manually 
operated transmit/receive switch. 

Requirements of dynamic output power control can be made. 
In such a case, these are stated in reference Rl-06. 

There is to be a control circuit, independent of all other 
logic,, which prohibits the continuous transmission of 
carrier for longer periods than 10 minutes. 



2.3.3 Audio muting 

The voice signal to the transmitter to be "muted during 
data transmissions. 
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2.4 RECEIVER CONTROL 

2.4.1 Frequency " 

The receiver frequency is controlled by the control unit. 

For information about frequency band and channel numbering 
plan to be used, please refer to document Rl-06. 

2.4.2 Squelch control 

There must be no squelch function in the receiver. 



2.4.3 Signal strength indication 

The received signal strength level is used in the roaming 

algorithm for selection of base station. 

Please refer to chapter RECEIVER in this document which 

includes a specification of the signal strength 

indication. 

2.4.4 Audio muting 

Whenever a data signal is detected, e.g detection of frame 
synchronization, the receiver voice output should be 
muted. 



Exhibit 2, p. 681 





1056 - A 296 5173/04 Ue 


Cantel Mobitex- 


T990-02-25 '""a 1 MTS18.2 



3 PERFORMANCE AND TECHNICAL REQUIREMENTS 



3 . 1 GENERAL 

For definitions and measurement methods, please refer to 
Appendix A. 

3.1.1 Frequency range 

For information about which frequency band and channel 
numbering plan etc that will be used, please refer to 
document Rl-06. 

3.1.2 Frequency error 

• The frequency error of— the transmitter and receiver shall 
not exceed {+)(-) 1.5 ppm. 
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3.1. 3 Data transmission 
3.1.3.1 Modulator 



Logic 


Level 


NRZ 


Lowpass 




VCO 


seq. 


shifter 


waveform 


filter 





J 



Figure 1. Block diagram of the method' of modulation. 

The modulation type is binary digital baseband filtered FM 
at a speed of 8 kbit/s. The method of modulation is shown 
in principle in Figure 1. The logic sequence to transmit 
is converted to a binary NRZ waveform by a level shifter 
and the NRZ waveform is filtered by a lowpass filter with 
linear, phase-characteristic. 

The filtered waveform is applied as control incut to a 
VCO, a voltage controlled oscillator. The lowpass filter 
reduces the deviation of the modulator for the high- 
frequency components of the binary modulating signal and 
thereby reduces the out of band emission of the 
transmitter. 

A sequence of logic I's should yield a transmitter 
frequency 2.0 kHz higher than the channel center 
frequency, A sequence of logic O's should yield a 
transmitter frequency 2.0 kHz lower than the channel 
center frequency. That is the modulation index is 0.5. 

The filter (or the equivalent filter in case of an other 
implementation) shall be a low pass filter with linear 
phase characteristic and a 3-dB frequency of 2.4 kHz. At a 
frequency two {2} times the 3-dB frequency the attenuation 
of the filter shall be 12 dB, and at a frequency four (4) 
times the 3-dB frequency the attenuation of the filter 
shall be 48 dB. The high frequencv roll-off of the filter 
must be at least 40 dB/octave. A high frequency 
attenuation of 70 dB is considered sufficient. Figure 2 
shows the amplitude response of the filter. The frequency 
modulator should be of a wide band linear type with 
frequency independent response in the frequency range 0 - 
4 kHz or otherwise compensated in the baseband filter. 
An eye diagram of the transmitted signal is shown in 
Figure 3. 
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— 0 2 4 6 S 10-12 Freq. (kHz) - 

Figure 2. Amplitude response of lowpass filter. 




Figure 3. Eye diagram. 



A preferred implementation of the baseband processing is 
oversampling of the bit-stream 4-8 times and digital 
filtering in a FIR (finite impulse response) filter with 
symmetric coefficients. This type of imDlementation can be 
realized by simple table look-up in a PROM. 

The modulation rate is 8 kbits per second. The frequency 
error of the bitrate clock should not exceed. +-10 ppm. 
The error of the modulation index should not exceed +- 5 
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3.1.3.2 Demodulator 



The demodulator should be of non-coherent type. A simple 
decision feedback or sequence detector should be used to 
resolve the small receiver eye opening of two subsequent 
bit transitions. A required bit error rate (BER) curve as 
a function of receiver input in a static receiver noise 
limited situation is shown in Figure 4. 

The performance requirement of the complete receiving 
equipment when connected to a reference data transmitter 
is that the decoded block error rate should be less than 
0.1 at the reference RF input signal level. At an RF input 
signal level 30 dB above the the reference level, the 
decoded block error rate should be less than 0.0001. 

It is essential that the demodulator keeps the synchronism 
with the incoming bit-stream during an entire message, ' 
even under disturbed conditions, in order to avoid 
repetition of other blocks than those which were actually 
disturbed. - ■ - - • - 



BER 
1E-1 




115 112 109 Receiver input (-dBm) 

Figure 4. Bit error rate versus receiver input level. 
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3.1.3.3 Start of data modulation 

Data modulation must not start until the carrier frequency 
is within its 200 Hz from its steady state value and che 
carrier power is within 2 dB from its steady state value. 

The transmitter carrier should be on for 5 -0/+5 ms before 
the start of transmission (frame head). 



3.1.3.4 Receive/transmit switching times 

The switching time from receive to transmit condition to 
be less than 20 ms including CPU handling time. 

The switching. time from transmit to receive condition to 
be less than 20 ms including CPU handling time. 



3.1.4 Test terminals 

Please note that the transceiver input/output terminals 
for voice must be accessible. 

An interface according to the "machine interface" defined 
in reference Hl-19, must be available during testing. 



'3.1.5 Test modulation 

Short and long frames as defined in the link layer will be 
used during tests of data transmission. 

It should be possible to force the modem to continuously 
transmit a sequence as specified iri the national 
requirements for out of band emission testing. 

It should be also be possible to force the modem to 
continuously transmit the scrambling sequence that is 
specified in Physical Layer Specification of the mobile 
terminal. 

Normal audio test modulation is a 1 kHz test tone at such 
a level that the resulting deviation is +- 1.5 kHz. 
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3.2 TRANSMITTER 

For definitions and measurement methods, please refer to 
Appendix A. 



3.2.1 Carrier power 

The nominal output power is stated in reference Rl-06. 
Requirements of dynamic output power control can be made. 
In such a case, these are also stated in reference Rl-06. 

Under normal, test conditions and independent of selected 
channel the carrier output power during carrier on 
condition to be within "(+)(-) 1,5 da of the nominal output 
power. Under extreme test conditions the carrier output 
power to be within +2 dB and -3 dB of the nominal output 
power. 

When the transmitter is in the carrier off condition, the 
carrier output power should not exceed 0,25uW. 



The transmitter to be able to withstand load tests as 
described below: 

-the change in the transmitter output power should -not 
exceed 2 dB during a load test when. the transmitter is 
loaded with a resistive load giving a standing wave ratio 
of 2. The test to be done at normal test conditions 
during 5 minutes of continuous transmission. 

-without being damaged the transmitter should be able to 
withstand the same test at extreme test conditions. 



-without being damaged the transmitter should be able to 
transmit for a period of 1 minute with the antenna 
terminal left open. 

-the last mentioned test to be repeated with the antenna 
terminal short-circuit. 
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3.2.2 Carrier rise and 


fall time 




The carrier rise time and carrier fall time are included 
in tne transmit-receive and receive-transmit switching 
SSi ^nL^ocument? 113 ^" -Aching 




3.2.3 Channel switching time 




The channel switching time should not exceed 30 ms. 




3»2*4 Frequency dsviflfcion 




3.2.4.1 Maximum permissible deviation 




T+)(^)2 i ? U ifH| e '™ iaaible frequency deviat i°n to be 




3.2.4.2 - Data modulation 




A long sequence of logic l's (0's) should produce a 
carrier frequency deviation of + {-, for 0's) 2.0 kHz 
+- 0.1 kHz. 




3 • 2* 4.3 Audio modulation 




The normal audio test tone will produce a deviation 
of +- 1.5 kHz. 




3.2.4.4 Audio frequency response 




The audio frequency response, measured through the audio 
signal input terminal, should have a 6 dB/octave pre- 
eraphasis between 300 Hz to 2500 Hz. For frequencies higher 
than 3000 Hz, the frequency response should have a roll- 
off of at least 30 dB/octave. 
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Figure 5. 



Frequency deviation relative to 1 kHz at 
constant input level. 



3.2.5 Adjacent channel power 

The adjacent channel power should not exceed the value 
specified in the national technical requirements, in case 
such a value is specified in the national technical 
requirements. 

3.2.6 Harmonic distortion 

The harmonic distortion factor should not exceed 5%. 



3.2.7 Residual modulation 

The residual modulation should not exceed - 40 dB, 
• measured with a psophometric filter. 

The residual modulation should not exceed - 20 dB, 
measured without filter. 
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3.2.8 Modulation due to vibration 

The modulation due to vibration should not exceed -30 dB 
measured by a r.m.s. voltmeter and with a psophometric 
filter. 

Without the psophometric filter and measured by a peak-to- 
peak voltmeter the modulation should not exceed -14 dB. 



3.2.9 Audio muting 

An input muting device controlled by the control unit 
should be provided. The muting to be capable of causing at 
least 40 dB attenuation in the voice path. Data 
transmission is not to start until the muting has reached 
an attenuation of 40 dB. 



.•V23Z51S3.3 
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3 . 3 RECEIVER 

For definitions and measurement methods, please refer to 
Appendix A. 

3.3.1 Channel switching time 

The channel switching time should not exceed 30 ms 
including data signal detection time. 

3.3.2 Squelch opening and closing levels and delays 
There must be no squelch function in the receiver. 

3.3.3 Signal strength indication 

The signal strength to be indicated by the receiver to the 
control unit. 

The indicated range to be : 

RF-level . 0-50 dBuV eraf with a monotonic output 

and absolute accuracy of 

+-(2 +10 % of actual value) dBuV emf. 

The time constant to be 1 ms. 



3.3.4 RF sensitivity 

The receiver sensitivity (speech) not to exceed 0 dBuV emf 
under normal test conditions and + 4 dBuV emf under 
extreme test conditions . 



The reference signalling sensitivity (data) not to exceed 
0 dBuV emf under normal test conditions , and 3 dBuV emf 
under extreme test conditions. 

The multipath signalling sensitivity (data) must not 
exceed 12 dBuV emf. This measurement is oniy done under 
normal test conditions. • 
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3.3.5 Adlacent channel selectivity 




The receiver shall comply with applicable national 
technical requirements. 




3.3.6 Spurious respons 


e rejection 




■ The receiver shall comply with applicable national 
technical requirements. 




3.3.7 Co-channel reiection 




The measurement is made with the wanted signal at an input 
level of +10 dBuV emf . 




The co-channel rejection level at any frequency 
displacement of the unwanted signal within the specified 
range to be greater than -2 dBuV emf. 




3.3.8 Intermodulation 


response 




The receiver shall comply with applicable national 
technical requirements. 




3.3.9 Blocking 






The receiver shall comply with applicable national 
technical requirements. 




3,3.10 Amplitude characteristic of the receiver 




Por the specified change of radio frequency input level, . 
the change of the audio output level should not exceed 3 
dB between the maximum and minimum output levels. 




3.3.11 AM-suppression 






The AM-suppression should not be less than 30 dB. • 




3.3.12 Audio frecruency response 




The audio frequency response, measured at the audio output 
terminal, should be within the limits as shown in the 
figure below. 



AM251SJ3 
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300Hz 1000Hz 3000Hz 

Figure 6 . Audio power relative to 1kHz at constant 
frequency deviation. 

3.3.13 Harmonic distortion 

At all audio frequencies used in the measurement and under 
all test conditions the harmonic distortion factor should 
not exceed 5%. 



3.3.14 Noise and hum 

The receiver "noise and hum" ratio should not exceed -40 
dB measured by a- r.ra.s. voltmeter and with a psophoraetric 
filter. 

Without the psophometric filter and measured by a peak-to- 
peak voltmeter the "noise and hum" ratio should not exceed 
-20 dB. 
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3.3.15 Audio output due to vibration 

The noise and hum ratio of the receiver due to vibration 
should not exceed -30 dB measured by a r.m.s. voltmeter 
through a psophometric filter. 

Without the filter and measured by a peak-to-peak 
voltmeter the the ratio should not exceed -14 dB. 



3.3.16 Audio muting 

An output muting device controlled by the control unit to 
be provided. The muting device to be capable of causing at 
least 40 dB attenuation in the voice path. 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Rl-06, 6, 
Rl-19, 12 



7, 8, 13 



Below are the reference designations listed. 
Reference Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 
Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Phys i cal laye r , • mob i le te rmi nals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 
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Appendix A, Measurement methods 



1 INTRODUCTION 

This document is an Appendix to MOBITEX TERMINAL 
SPECIFICATION - RADIO EQUIPMENT. It consists of 
requirement definitions and measurement method 
descriptions. 

The measurement values applies to 12,5 kHz channel spacing 
in the 900 MHz frequency band. 

The document describes measurement methods for several 
data transmission speeds. Therefore, measurements without 
specified requirement procedures in the main document can 
be found. These should be ignored. 

The equipment specified in this document should also meet 
with basic requirements set up in national regulations for 
radio transmitters and radio receivers. 
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2.1 SYSTEM MEASUREMENTS 



2.1.1 Receive to transmit switching time 
Definition: 

The switching time from receive to transmit condition is 
defined as the elapsed time from the end of an incoming 
frame with the response flag set, to the beginning of the 
response, i.e. the data signalling starts (see main 
document "Start of data modulation" ) . 

2.1.2 Transmit to receive switching time 
Definition: 

The switching time from transmit to receive condition is 
defined as the elapsed time from end of the last frame in 
a message sent by the transmitter, until the receiver is 
capable of detecting incoming data sighals. 

2.1.3 - Channel switching time 
Definition: 

The channel switching time is defined as the elapsed time 
from the end of a received order to change channel, until 
the receiver is capable of detecting data signals on the 
new channel. 



2.1.4 Frequency error 
Definition: 

The frequency error of the transmitter is the difference 
between the measured carrier frequency and its nominal 
value . 

Method of measurement: 

The carrier frequency should be measured in the absence of 
modulation with the transmitter connected to an artificial 
antenna. 

The test should be made under normal and extreme test 
conditions. 
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2.2 TRANSMITTER MEASUREMENTS • 




2.2.1 Carrier power 






Definition: 






The transmitter carrier power is the mean power delivered 
to the artificial antenna during a radio frequency cycle 
in the absence of modulation. 




Method of measurement: 






The transmitter should be connected to an artificial 
antenna and the power delivered to this artificial antenna 
should be measured. 




The measurements should be made under normal and extreme 
test conditions.- 




2.2.2 Maximum permissible freouency deviation 
Definition: 




The frequency deviation is the maximum difference between 
the instantaneous frequency of the modulated radio 
frequency signal and the carrier frequency in the absence 
of modulation. 




Method of measurement: 






The frequency deviation should be measured at the output 
of the transmitter connected to an artificial antenna, by 
means of a deviation meter capable of measuring the 
maximum deviation, including that due to any harmonics and 
interraodulation products which may be generated in the 
transmitter. 




2.2.3 Audio frequency response 




Definition: 






The audio frequency response is the frequency deviation of 
the transmitter carrier as a function of modulation 
frequency at a constant level of the modulation signal. 




Method of measurement: 










A modulation signal at a frequency of 1000 Hz and adjusted 
to such level that a frequency deviation of (+)(-)0,5 kHz 
is obtained, is applied to the transmitter. The frequency 
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of the modulation signal is then varied between 300 Hz and 
25 kHz, its level being <cept constant. The connection 
values of frequency deviation and modulation frequency 
should be determined. 



2-2.4 Adjacent channel power 
Definition: 

The adjacent channel power is that part of the total power 
output of a transmitter under defined conditions of 
modulation, which falls within a specified Dassband 
centred on the nominal frequency of either of the adjacent 
channels. This power is the sum of the mean power produced 
by the modulation, hum and noise of the transmitter. 



Method of measurement: 

The adjacent channel power should be measured with a power 
measuring receiver which fulfills the requirements given 
in the CEPT recommendation T/R 24-1. The transmitter 
should be operated at the nominal carrier power under 
normal test conditions. The output of the transmitter 
should be linked to the input of the receiver by 
connecting device such that the impedance presented to the 
transmitter is 50 ohms and the level at the "receiver- 
input is appropriate. 

The transmitter should be modulated with a signal of 1250 



The signal of 1250 Hz should be adjusted to a level 20 dB 
higher than that required to produce (+}(-)l,5 kHz 
deviation. The "receiver" should be tuned to the nominal' 
frequency of the transmitter and the variable attenuator 
in the "receiver" should be adjusted to a vaiue p dB such 
that a meter reading of the order of 5 dB above the 
"receiver" noise level is obtained. 

The "receiver" should then be tuned to the nominal 
frequency of one of the adjacent channels and the variable 
attenuator should be adjusted to a value q dB such that 
the same meter reading is obtained. 

The measurement should be repeated with normal data test 
modulation (paragraph Test modulation, in the Main 
document ) . 

The ratio of adjacent channel power to carrier Dower is 
the difference between the attenuator settings p and q. 
The adjacent channel power is determined by applying this 
ratio to the carrier power. 
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2.2.5 Harmonic distortion 
Definition: 

The harmonic distortion factor of a transmitter modulated 
by an audio frequency signal is defined as the ratio, 
expressed as a percentage, of the r.m.s. voltage of all 
the harmonic components of the fundamental audio frequency 
to the total r.m.s. voltage of the signal after linear 
demodulation. 

With the method described below, when a distortion meter 
is used, the hum and noise components are included in the 
distortion measurement. 



Method of. measurement:.--— 

The radio frequency signal produced by the transmitter is 
applied, by means of a suitable coupler, to a linear 
demodulator equipped with a de-^emphasis network of 6 dB 
per octave. 

The radio frequency signal to be modulated successively at 
frequencies of 300, 500 and 1000 Hz frequency to (+)(-}1.5 
KHz deviation. 

The harmonic distortion factor of the audio frequency 
signal is measured at all the frequencies given above. 



2.2.6 Residual modulation 
Definition: 

The residual modulation of the transmitter is the ratio, 
expressed in dB, of the audio frequency noise level 
produced after radio frequency signal demodulation, in the 
absence of modulation, by the wanted signal, by the 
spurious effects of the power supply system, by the 
modulator or by other causes, to the audio frequency level 
produced by normal test modulation applied to the 
transmitter. 

Method of measurement: 

a) The normal test modulation is applied to the 

transmitter. The RP signal produced by the transmitter 
is applied by means of a suitable coupler to a linear 
demodulator. 



Exhibit 2, p. 701 



Cantel Mobitex- 



A/1056 - A 296 5173/01 Ue 



1990-02-23 C 



The demodulator is equipped with a de-emphasis network 
of 6 dB per octave. 

All precautions .should be taken to prevent the 
measurement results from being affected by emphasis at 
the low audio frequencies of the internal linear 
demodulator noise. 

Measurements to be carried out on the demodulator 
output signal by means of an r.ra.s. voltmeter equipped 
with psophometric filter network described in CCITT 
Recommendation P. 53 .A. 

The modulation is then removed and the level of the 
residual audio frequency output signal is again 
measured. 

b) The same method as a) above but without the 
psophometric filter at the output. 

-.-JLti.fc.his case .the measurements are carried out by means 
of a peak-to-peak voltmeter. 



2.2.7 - Modulation due to vibration 
Definition: 

Modulation due to vibration denotes the ability of the 
transmitter to withstand influence on the radio frequency 
output signal by mechanical vibrations. 



Method of measurement: 

The residual modulation is .measured in accordance with 
5.2.2. The transmitter should during the test be vibrated 
in each of three directions: 

10 - 100 Hz 1 ra/s 2 

sweep rate 1 octave per minute 
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2.3 RECEIVER MEASUREMENTS 



2.3.1 RF sensitivity 
Definition: 



The maximum usable sensitivity of the receiver is the 
minimum level of signal (emf) and field-strength 
respectively at the receiver input, at the nominal 
•frequency of the receiver, with normal test modulation 
which will produce: 

an audio-frequency output power of at "least 50% of the 
rated power output and 

a SND/ND ratio (S=signal, N=noise, D=distortion) of 20 dB, 
measured at the receiver output through a telephone 
psophometric weighting network as described in CC1TT 
Recommendation P.53-A. 

Note: The characteristics of the 1" kHz band-stop filter 
used in SND/ND measurements should be such that at 
the output the attenuation at 1 kHz will be at least 
40 dB and at 2 kHz will not exceed 0.6 dB, The 
filter characteristics should be flat within 0.6 dB 
over the ranges of 20 Hz to 500 Hz and 2 kHz to 4 
kHz. In the absence of modulation of the total noise 
power at the audio-frequency output of the receiver 
under test. 

The reference signalling sensitivity data is the level and 
field-strength respectively of a radio frequency input 
signal at the nominal receiver frequency and modulated 
with the normal coded test signal or pseudo- random bit 
sequence which will produce a successful calling ratio of 
80% for signalling systems with a specific response as 
output and a bit error ratio of 0.01 for. data transmission 
systems with a bit stream as output respectively. 

Measurement methods: 

A signal of carrier frequency equal to the nominal 
frequency of the receiver and with normal test modulation 
shall be applied to the receiver input terminals. An audio 
frequency output load and a distorsion factor meter 
incorporating a 1 kHz band-stop filter and a psophometric 
telephone weigthing network shall be connected to the 
receiver output terminals. Where possible, che receiver 
volume control shall be adjusted to give at lease 50% of 
the rated output power. The test signal input level shall 
be reduced until a SND/ND ratio of 20 dB is obcained. The 
test signal input level under these conditions is the 
maximum usable sensitivity. The measurement shall be made 
under normal test conditions and extreme test conditions. 
Under extreme test conditions, a variation of the receiver 
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output power of (+){-) 3 dB from the value obtained under' 
normal test conditions may be allowed. 

A signal of carrier, frequency equal to the nominal 
frequency of the receiver and modulated with the normal 
coded test signal or a psuedo-random bit sequence shall be 
applied to the receiver input terminals. The level of this 
signal shall be such that a successful calling ratio of 
SCR = 80%, and a bit error ratio of BER =0.01 respective- 
ly is obtained. The reference signalling sensitivity 
(data) is the maximum level of the levels recorded for SCR 
= 80% and BER = 0.01. 

The multipath signalling sensitivity is the rms value of 
the level of a Rayleigh fading input signal at the nominal 
receiver frequency and modulated with the normal coded 
test signal or pseudo-random bit sequence which will 
produce a sucessful calling ratio of 80% and a bit error 
rate of 0.01. The measurements shali be carried out with a 
Rayleigh fading simulator set for a simulated vehicle 
speed of 90 km/h and repeated for , a simulated vehicle 
speed of 50 km/h and 10 km/h. The reference multipath 
signalling sensitivity (data) is the maximum neccessary 
level of the multipath measurements. 



2.3.2 Adjacent channel selectivity 
Definition: 

The adjacent channel selectivity is a measure of the 
capability of the receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the 
presence of an unwanted modulated signal which differs in 
frequency from the wanted signal by an amount equal to the 
adjacent channel separation, for which the equipment is 
intended. 

Method of measurement: 

Two signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and be modulated with 
normal test modulation. The unwanted signal should be at 
the nominal frequency of the upper adjacent channel and be 
modulated with a 400 Hz tone to a frequency deviation of 
(+)(-)l,5 kHz. 

Initially the unwanted signal should be switched off and 
the level of the wanted signal should be adjusted to 6 
dBuVemf. The unwanted signal should then be switched on 
and its level adjusted until the SND/ND ratio, measured at ■ 
the receiver .line output terminal through the psophometric 
filter,- is reduced to 14 dB. 



1 
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The measurement should be repeated with the unwanted 
signal at the nominal frequency of the lower adjacent 
channel . 

The adjacent channel selectivity should be expressed as 
the lower value of the receiver input levels in dBuV emf 
of the unwanted signal for the upper and lower adjacent 
channels . 



2.3.3 Spurious response rejection 
Definition: 

The spurious response rejection is a measure of the 
capability of the receiver to discriminate between the 
wanted modulated signal of the nominal "frequency and an 
unwanted signal at any other frequency at which a response 
is obtained. 



Method of measurement: 

Two input signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and be modulated with 
normal test modulation. Initially the unwanted signal 
should be switched off and the wanted input signal 
adjusted to 6 dBuV emf. The unwanted signal should be 
switched on and modulated with a 400 Hz tone to a 
frequency deviation of (+)(-)l,5 kHz. The input level of 
the unwanted signal should be 86 dBuV emf and its 
frequency should be varied at least from 100 kHz to 2000 
MHz . 

At any frequency at which a response is obtained, the 
input level of the unwanted signal should be adjusted 
until the SND/ND ratio, measured at the line output 
terminal of the receiver ..through the psophoraetric filter, 
is 14 dB. 

The spurious response rejection should be expressed as the 
level in dB of the unwanted signal relative to 1 uV emf 
at the receiver input when the SND/ND ratio of 14 dB, as 
mentioned above, is obtained. 



2.3.4 Co-channel rejection 
Definition: 

The co-channel rejection is a measure of the capability of 
the receiver to receive a wanted modulated signal without 
exceeding a given degradation due to the presence of an 
unwanted modulated signal, both signals being at the 
nominal frequency of athe receiver . 
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Method of measurement: 



Two input signals should be applied to the receiver via a 
combining network. The wanted signal should have normal 
test modulation. The unwanted signal should be modulated 
with a frequency of 400 Hz to a frequency deviation of 
(+)(-) 1,5 kHz. Both input signals should be at the nominal 
frequency of the receiver and the measurement should be 
repeated for displacements of the unwanted signal up to 
(+)(-)l/5 kHz offset frequency of the nominal frequency. 

Initially the unwanted signal should be switched off and 
the level of the wanted signal should be adjusted to +6 
dBuV emf.The unwanted signal should then be switched on. 

The level of the unwanted signal should be adjusted until 
the SND/ND ratio, measured at the line output terminal of 
the receiver through the psophometric filter, is reduced 
to 14 dB. 

The. co-channel rejection should be expressed as the ratio 
in dB of the level of the unwanted signal to the level of 
the wanted signal at the receiver input for which . SND/ND = 
14 dB at the receiver line output terminal occurs. 



2.3.5 Intermodulation response 



Definition: 

The intermodulation response is a measure of the 
capability of the receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the 
presence of two or more unwanted signals with a specific 
frequency relationship to the wanted signal frequency. 



Method of measurement: 

Three signal generators. A, B and C, should be connected 
to the receiver via a combining network. 

The wanted signal, represented by signal generator A, 
should be at the nominal frequency of the receiver and 
should have normal test modulation. 

The unwanted signal from signal generator B should be 
unmodulated and adjusted to the frequency separated by 25 
kHz above the nominal frequency of the receiver. 

The second unwanted signal from signal generator C should 
be modulated with a frequency of 400 Hz with a deviation 
of 1,5 kHz and adjusted to the frequency 50 kHz above the 
nominal frequency of the receiver. 




Exhibit 2, p. 



Cantel Mobitex- 



A/1056 - A 296 5173/01 Ue 



The amplitude of the wanted input signal should be 
adjusted to 6 dBuV emf . The amplitude of the' two unwanted 
signals should be maintained equal and should be adjusted 
until the SND/ND ratio at the receiver output, . 
psophometrically weighted, is reduced to 14 dB. 

The frequency of signal generator B should be adjusted 
slightly, if necessary, to produce the maximum degradation 
• of the SND/ND ratio. The level of the two unwanted test 
signals should be readjusted to restore the SND/ND ratio 
of 14 dB. 

The measurement should be repeated with the unwanted 
signal B at 2S kHz below that of the wanted signal and the 
frequency of the unwanted signal C at 50 kHz below that of 
the wanted signal. 

The intermodulation response level is the receiver input 
level in dB produced by each of the two unwanted Signal 
generators relative to 1 uV emf. 



2.3.6 Blocking 
Definition: 

Blocking is- a change (generally a reduction) in the wanted 
output power of a receiver or a reduction of the SND/ND 
ratio due to an unwanted signal on another frequency. 

Method of measurement: 

Two input signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and should have normal 
test modulation. Initially the unwanted signal should be 
switched off and the input level of the wanted signal 
should be adjusted to 6 dBuV emf. 

The output power of the wanted signal at the line output 
terminal of the receiver should be adjusted to the nominal 
output level. Then the unwanted signal should be switched 
on. The unwanted signal should be unmodulated, and its 
frequency should be varied between +1 MHz and +10 MHz, and 
also between -1 MHz and -10 MHz, relative to the nominal 
frequency of the receiver. The input level of the unwanted 
signal, at all frequencies in the specified ranges, should 
be so adjusted that the unwanted signal causes: 

a) a reduction of 3 dB in the audio frequency output power 
of the wanted signal, 

or 

b) a reduction of the SND/ND ratio to 14 dB, measured 
.through a psophometric filter. 
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whichever occurs first. 



This input level is the blocking level" at the frequency 
concerned. 



2.3.7 Amplitude characteristics 
• Definition: 

The amplitude characteristics of the receiver is the 
relationship between the radio frequency input level of 
specified modulated signal and the audio-frequency level 
at the receiver output. 



Method of measurement: 

A test signal at a level of 6 dBuV emf at the nominal 
frequency of the receiver and having normal test 
modulation should be applied to the receiver input. The 
audio frequency power at the line output should be 
adjusted to the nominal level. The input signal should be 
increased to 100 dBuV emf, and the audio frequency output 
level should again be measured. 



2.3.8 AH-suppression 
Definition: 

AH-suppression is the capability of the receiver to 
suppress amplitude modulated signals. It is expressed as 
the ratio in dB of the audio power at the line output 
terminal with normal test modulation to the audio power 
with a specified amplitude modulation. 



Method of measurement: 

A test signal at a level of 20 dBuV emf and 60 dBuV emf at 
the nominal frequency of the receiver to be applied to the 
receiver input successively. The signal should initially, 
have normal test modulation and the voice output terminal 
power should be set to the nominal output level. The 
normal test modulation should then be replaced by 
amplitude modulation to 30% with a 1000 Hz tone. The audio 
power should again be measured. It may be necessary to 
make this measurement with a selective voltmeter. 



2.3.9 Audio frequency response 
Definition: 
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The audio frequency response of the receiver expresses the 
variation in the audio- power at the line output terminal 
as a function of the modulation frequency of the input 
signal. 



Method of measurement: 

A test signal at a level of 60 dBuV emf at the nominal 
frequency of the receiver and having normal test 
modulation to be applied to the receiver input. 

The audio power to be adjusted to 50 % of the rated output 
power. This setting is not to be altered during the test. 

The frequency deviation at 1000 Hz then should be reduced 
to (+)(-)0,5 kHz and maintained constant while the 
modulation frequency is varied at least between 300 Hz and 
5000 Hz. 

--The~"measu'rement is repeated with the test signal- - 
successively at plus and minus 1,25 kHz from the nominal 
frequency' of the receiver . 



2.3.10 Harmonic distortion 
Definition: 

The harmonic distortion factor at the voice output 
terminal of the receiver is defined as the ratio, 
expressed as a percentage, of the r.m.s. voltage of all 
the harmonic components of the fundamental audio frequency 
to the total r.m.s output voltage. 

With the method of measurement described below in case a 
distortion meter is used, the hum and noise components are 
included in the distortion measurement. 



Method of measurement: 

Test signals of 60 dBuV emf and 100 dBuV emf at the 
nominal frequency of the receiver should be applied 
successively to the receiver input. 

In each measurement the audio power at the voice output 
terminal should be adjusted to the nominal output level. • 

The test signal to be modulated successively with 300, 500 
and 1000 Hz tones to (+)(-) 1,5 kHz frequency deviation 
and the harmonic distortion is measured at each frequency. 

Dnder extreme test conditions, tests to be carried out at 
the nominal frequency of the receiver as well as at plus 
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and minus 1,25 kHz from the nominal frequency. In. this 
case the input signal is modulated only. with a 1000 Hz 
tone to a ftequency deviation of (+){-) .1,5 kHz. 

2.3.11 Noise and hum 
Definition: 

The "noise and hum" of the receiver is the . ratio, expressed 
in decibels, of the. audio frequency noise and hum level 
resulting from the spurious effects of the power supply 
system or from other causes to the audio frequency level 
produced by RPrsignals as specified below and applied 
to the receiver input. 

Method of measurement: 

a) A test signal at a level of 30 dBuV emf at the nominal, 
frequency of the receiver and having normal test 

modulation, should be applied to the receiver input.' A' 

psophometric filter to be connected at the voice output 
terminal. The audio power to be adjusted to nominal 
level. 



The modulation is then removed and the audio power 
measurement is repeated. 

i The same method as in case a) above, but without the 
psophometric filter and using a peak-to-peak voltmeter 
for the measurement. 



2.3.12 Audio output due to vibration 
Definition: 

Audio output due to vibration denotes the ability of the 
receiver to withstand influence on a received radio 
frequency signal by mechanical vibrations. 

Method of measurement: 

The noise and hum of the receiver is measured in. 
accordance with 5.3.6. The receiver should during the test 
be vibrated in each of 3 directions. 

10 - 100 Hz 1 m/s 2 

sweep rate 1 octave per minute 
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During the vibration the radio frequency test signal 
should be unmodulated and the level of the receiyer output 
signal should be measured. 
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2.4 MEASUREMENT ACCURACY 






The measurement instrumentation should have at least the 
accuracy given below: 


D.C voltage 




+ 


t")l% 


A.C mains voltage 




+ 


M3t 


A.C mains frequency 




( + 


(-)0,5% 


Audio- frequency voltage. 


power, etc. 


+ 


(-)0,5 dB 


Audio-frequency 




+ 


(-)0,1% 


Distortion and noise, etc of audio 
frequency generators 


+ 


M0,3% 


Radio frequency 




+ 


(-)20 Hz 


Radio frequency voltage 




+ 


(-)2 dB 


Radio- frequency field strength 




(~)3 dB 


Radio-frequency carrier power 


+ 


(~)5% 


Impedance of artificial loads, 
combining units,, cable, plugs, 
attenuators, etc. 


+ 


(")5% 


Source impedance of generators and 
input impedance of measuring receivers 


+ 


(-)10% 


Attenuation by attenuators 
Temperature 


+ 
+ 


(-)0,5 dB 

(-)i 6 c 


Humidity 




+ ] 


t-)5% 


Time 




+ ) 


(-)10% 



A232S1SM 
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MOBITEX 

Other interfaces, mobile terminal 
and fixed terminal 



ABSTRACT 

This document specifies the interfaces between the MOBITEX 
network and a mobile or fixed terminal connected to the 
network. 
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1 INTRODUCTION 
1.1 GENERAL 

The purpose of this specification is to give well defined 
interfaces for the connection of application equipment. This 
specification will serve as a recommendation for the mobile 
terminal market. 

NOTE; The Radio/MCO must be type-tested with a terminal of 
"masc" type. A minimum number of commands (defined by 
document Mobitex ASyncronous Communication, APPENDIX 
A, Commands) are then required. 
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2 GENERAL DESCRIPTION 

The picture belaw shows the mobile terminal system parts. 



MOBILE TERMINAL 



AUDIO-EQUIPMENT | 



"j OP-TERMINAL 



MOBILE TERMINAL s complete equipment 
MCU : mobile control unit 

AUDIO-EQUIPMENT : equipment like mic/speaker , handset 
OP— TERMINAL : terminal for operators 

EMERGENCY EQU. : equipment like emergency receiver, emergency 
button 

2.1 Terminal interface 

Asynchronous, serial data transmission. Permitted transmission 
rates are 600, 1200, 2400, 4800 and 9600 Baud. However, for 
"masc" type terminals 600 baud is not permitted. Default value 
is 1200 Baud. In MCU it must be possible to set any of these 
baud .rates by hardware switches or alike. It must be possible 
to set the baud rate of each -output separately. Normally 1 
start bit, 8 data bits, 1 stop bit and no parity is used. 
However, masc type terminals should use 7 data bits and even 
parity. 

2.1.1 Printer/data collection unit 

Interface designed to connect a printer or any other character 
(text) oriented terminal. It can also be used for data 
collection units. This interface must be combined with one or 
more of the other terminal interfaces. The 7 most significant 
bits are coded according to MOBITEX TEXT CODE, see reference 
Rl-06. The eighth bit is set to logical zero. 
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2.1.2 Terminal with small display 

Designed for connection to a unit with a limited text display 
area and from which the. operator can enter numbers, status 
messages and text including simple text editing. The editor is 
placed in MCO. Also the audio equipment and the manual mode of 
the radio equipment can be handled from this unit. Character 
oriented format {as above) is used. 



2.1.3 ANSI terminal 

For connection of asynchronous full screen terminal which 
complies with terminal interface ANSI X 3.41 1964 and 
ANSI X 3.64 1979 with respect to cursor control and editing 
functions . 

Prom. the terminal the operator can enter numbers, status 
messages and text including text editing. The editor is placed 
in MCU. Character oriented format as above. 



2.1.4 "MASC" type terminal 

Connection of units with the capacity to handle complete data 
packets (MPAK) , e.g. a personal computer. The format is block 
oriented which means that information is' transmitted in the 
form of packets (MPAK) according to the format which is given 
in the network layer specification. Control of the complete 
mobile terminal, e.g. audio equipment and manual mode, is 
performed by special commands included in the protocol. The 
interface also contains functions for reading status parameters 
in the mobile terminal (meant for the type test). 7 bits per 
character and even parity to be used. Permitted transmission 
rates, are 1200, 2400, 4800 or 9600 Baud. 

For type testing, a masc type interface is required. In this 
case it may be implemented by external adaptors. 



2.2 Audio interface 

Connection of microphone and loudspeaker or handset. The 
interface also contains certain control functions. The handset 
can be combined with numeric and status keys. The same 
character codes as for the terminal with small display are 
used. The audio interface can also be combined with the 
terminal interface. Refer also to the application examples. 



2.3 Emergency interface 

Connection facilities for four units. Three connections are for- 
emergency buttons and one is for a receiver for receiving 
emergency transmissions generated by a portable transmitter. 
Any of these units can initiate the emergency procedure in MCU. . 
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3 TERMINAL INTERFACE 

This chapter describes the interface to equipment which 
communicates with MCO in serial form. 



3.1 PHYSICAL INTERFACE 

The physical interface is the same for all terminal types. 

The terminal interface uses a 25-pole DSOB socket (female 
socket with pins) with the following configuration: 



PIN 


V.24/V.28 


V.10 category 1/V.ll 


SOURCE 


1 


supply ground 


supply ground 






2 


transmitted data 


transmitted data 


A 


DTE 


3 
4 


received data 
* 


received data 


A 


1 MCU 


5 
6 


data set ready 


data set ready 


A 


MCU 


7 


signal ground 


signal ground 






8 




data terminal ready 


B 


DTE 


9 


system start (ground 


system start (ground) 


DTE 


10 


system start (+12V) 


system start (+5V) . 




DTE 


11 




* 






12 


* 








13 


* 








14 




transmitted data 


B 


DTE 


15 




received data 


B 


MCU 


16 .. 




* 






17 




* 






18 




data set ready 


B 


MCO 


19 










20 
21 


data terminal ready 


data terminal ready A 


DTE 


22 


ring ind. 


ring ind. 




MCO 


23 




* 






24 


-12V (supply) 


* 




MCU 


25 


+12V (supply) 


+5V (supply) 




MCU 



Fins 9, 24 and 25 differ from V.28; Pins 9, 10, 24 
and 25 differ from V.24. 

The following applies to V10: 0 or ON is when A > B 
and 1 or OFF is when B > A. 



The following applies to V28: 0 or ( 
and 1 or OFF is when V < -3V. 



is when V > 3V 
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The transmission rate for serial data is 600, 1200, 
2400, 4S00 or 9600 baud. 

The signal "DATA SET READY" is activated as soon as 
HCO is ready to transmit. The signal to be activated 
when it is not used. 

An active signal means that the physical layer is in 
the data transmission mode. 

System Start, activating MCD from equipment not 
according to V.28. 

MCD starts up within 10 seconds when pin 9 is 
activated (ON condition) . MOT then remains on until 
all system start signals are inactivated. 
ON conditions voltage 0V - +1V; current less 

than 5 mA. 
OFF -condition: not connected or 

voltage +2V - +15V: current less 

than 5 mA. 

System Start, activating MCD by signal according to 
V.28. 

MCD starts up within 10 seconds when pin 10 is 
activated. MCU then remains on until all system 
start signals are inactivated. • 
ON condition: voltage > 3V (see V28). 

OFF condition: not connected or 

voltage < -3V. (see V28). 

The signal "DATA TERMINAL READY" is activated as 
soon as the terminal is ready to receive. The signal 
is to be activated when not used. 

An active signal means that the physical layer is in 
the datatransmission mode. 

The signal "RING INDICATION" is used to activate the 
periferal unit. 

- 12 V/100 mA supply for connected equipment. 

+ 12 V (+ 5 V)/500 mA supply for connected 
equipment . 
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3.2 PROTOCOL FOR PRINTER/DATA COLLECTION UNITS 



General 

Interface designed to connect a printer or any other character 
(text) oriented terminal. It can also be used for data 
collection units. This interface must be combined with one or 
more of the other terminal interfaces. 



Receiving text 



To stop the data stream from MCO temporarily, the printer sends 
XOFF (DC3) to MCO and to restart the data stream it sends XON 
(DC1). 



Sending text 

Text can be sent to MCO. In MCO a complete MPAK will be created 
with sender and addressee before it is transmitted on the radio 
path. 

The connected unit stops sending when it has received XOFF 
( DC3 ) from MCO and does not start again until XON (DC1) is 
received. 
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3.3 PROTOCOL FOR TERMINALS WITH SMALL DISPLAY 



3.3.1 Receiving data 

To stop the data scream from MCU temporarily , the terminal 
sends XOFF (DC3) and to restart the data stream it sends XON 
(DG1). Received characters in the code range 32 - 126 (decimal) 
are printed out directly. Other codes are interpreted by che 
terminal according co the following table: 



CHARACTER CODE 


TERMINAL S INTERPRETATION Uf 


000 


NUL 




001 


SOH 




002 


STX 




003 


ETX 




004 


EOT 


- 


005 


ENQ 




006 


ACK 




007 


BEL 


give audible signal 


008 


as 


move cursor one step to left 


009 


HT 




010 


LF 


line feed 


011 


VT 




012 


FF 




013 • 


CR 


move cursor to beginning of line 


014 


SO 




015 


SI 




016 


DLE 




017 


DC1 


resume sending data 


018 


DC2 




019 


DC3 


stop sending data 


020 


DC 4 




021 


NAK 




022 


sra 




023 


ETB 




024 


CAN 




025 


EM 




026 


SOB 
ESC 




027 


carry out function as defined below 


028 


FS 




029 


GS 




030 


RS 




031 


OS 




127 


DEL 
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FUNCTION WHEN RECEIVED 



<ESC>[Ax 
<ESC>[Bx 
<ESO[Cx 



<ESC>[M 
<ESO[N 
<ESC>[0 

<ESO[P 
<ESC>[Q 
<ESO[R 

<ESC>[S 
<ESC>[T 
<ESC>[CJ 

<ESC>(Y 
<ESC>[Z 
<ESC>[[ 



place the cursor at position x 
insert character x at cursor position 
delete character at cursor and insert 
character x at end of line 
delete character at cursor and insert 
character x at beginning of line 
send user information 



display visible <CR> 
display visible <LF> 

LED1: on (contact with system) 

(green) blinking (no contact with system) 
off (power off) 

LED2: on (external call ind. on) 

(orange) blinking (no function) 

off (external call ind. off) 

LED3: on (Manual radio mode) 
(yellow) blinking (Call indication man. mode) 
off (MOBITEX) 
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3.3.2 Sending data 



The terminal stops when it has received XOFF (DC3) from MCU and 
does not restart until XON (DC1) is received. All characters 
are interpreted as when receiving except for the <ESC> 
sequences defined in the following table: 



SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>OA 


place cursor at beginning of text 


<ESC>OB 


place cursor at end of text 


<ESC>OC 


move cursor one step to the right 


<ESO0D 


move cursor one step to the left 


<ESC>OE 


user information follows (2048 octets) 


<ESC>OHxy 


display size: x=character/line, y=no. of line- 


<ESO0K 


user information missing 


<ESC>OM 


send message 


<ESC>OP 


LINE CONNECTION start 


<ESOQQ 


STATUS 


<ESO0R 


EMERGENCY ■ ™"" - - 


<ESO0W 


TELEX 


<ESC>OX 


DATEX 


<ESC>01 


copy 


<ESC>0ra 


lock 


<ESO0n 


LINE CONNECTION end 


<ESC>Oo 


external call indication on/off { toggle >. 


<ESOOp 


TEXT 


<ESO0q 


increase audio volume' 


<ESO0r 


decrease audio volume 


<ESOOs 


loudspeaker on/off (toggle) 


<ESO0t 


cancel 


<ESO0u 


TELEPHONE 


<ESO0v 


MANUAL RADIO MODE 



When the terminal is sending, the character DEL (decimal 127) 
is interpreted as the terminal wishing to remove the character 
to the left of the cursor. 

Following ASCII codes are used to control MANUAL RADIO mode: 



Q 

w X 


channel number where x=channel number 01 - 99 


E 


squelch on/off (toggle) 


R xxxxxxx 


selective call to xxxxxxx, x = 0 - 9 


T 


transmit call tone 


y 


loudspeaker on/off (toggle) 


u 


scanning 


i 


external call indication on/off (toggle) 
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3.4 PROTOCOL FOR ANSI TERMINAL 
3.4.1 Receiving data 

To stop the data stream from MCU temporarily, the ANSI terminal 
sends XOFF (DC3) and to restart the data stream it sends XON 
(DC1). Received characters in the code range 32 - 126 (decimal) 
ace displayed directly. Other codes are interpreted by the ANSI 
terminal according to the -following tables: 



CHARACTER 


CODE 


ANSI terminal's interpretation of character 


000 


NUL 




001 


SOH 


_ 


002 


STX 




003 


ETX 




004 


EOT 


- 


005 


ENQ 




006 


ACK 




007 


BEL 


give audible signal 


008 


BS 


move cursor one step to the left 


009 


HT 




010 


LF 


line feed 


011 


VT 




" 012 


FF 




013 


CR 


carriage return 


014 


SO 




015 


SI 




016 


OLE 




017 


DC1 


resume sending data 


018 


DC2 




019 


DC3 


stop sending data 


020 


DC 4 




021 


NAK 




022 


SYN 




023 


ETB 




024 


CAN 




025 


EM- 




026 


SUB 




027 


ESC 


carry out function as defined below 


023 


FS 




029 


GS 




030 


RS 




031 


US 
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SEQUENCE 


FUNCTION WHEN RECEIVING 


<ESC>[A 

<£SC>[3 

<ESC>[C 

<ESC>[D 

<ESC>[c 

<ESC>[0q 

<ESC>[lq 

<ESC>[2q 

<ESC>[3q 

<ESC>[4q 


cursor up one step 
cursor down one step 
cursor right one step 
cursor left one step 
restart of terminal from MCD 
switch off LED1 — LED4 (not ANSI) 
switch on LED1 (not ANSI) 
switch on LED2 (not ANSI) 
switch on LED 3 (not ANSI) 
switch on LED 4 (not ANSI) 



For the meaning of LED1 - LED 3 see terminal with small display. 

If additional functions are required, we recommend the use of 
functions and control sequences in accordance with 
ANSI X 3.41 1974. and ANSI X .3.64 19.79-.. 
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3.4.2 



Sending data 



The ANSI terminal stems sending when it has received XOPF (DC3) 
from MCU and does not" restart until XON (DC1) is received. All 
characters are interpreted as when receiving, except for the 
<ESC> sequences defined in the following table: 



SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>OA 


move cursor up one step 


<ESC>OB 


move cursor down one step 


<ESC>OC 


move cursor one step to the right 


<ESC>OD 


move cursor one step to the left 


<ESOOE 


<ESOOF 




<ESC>OG 




<ESC>OHxy 


display size: x=character/line,y=no. of lines 


<ESOOI 




<ESC>OJ 




<ESC>OK 


user information missing 


<ESC>OL 




<ESC>OM 


.send message 


<ESC>ON 




<ESC>00 




<ESC>OP 


LINE CONNECTION Start 


<ESC>OQ 


STATUS 


<ESC>OR 


EMERGENCY 


<ESC>OS 




<ESC>OT 




<ESC>OU 




<ESC>OV 




<ESC>OW 


TELEX {not in ANSI standard) 


<ESC>OX 


DATEX (not in ANSI standard) 


<ESOOY 




<ESC>OZ 




<ESC>0[ 




<ESC>0\ 




<ESC>0] 





{Continued on next page) 
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SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>Oa 




<ESC>0b 




<ESOOc 




<ESOOd 




<ESC>0e 




<ESOOf 


- 


<ESO0g 




<ESC>6h 




<ESC>Oi 




<ESO0j 




<ESOOk 




<ESC>01 


copy 


<ESO0m 


lock 


<ESO0n 


LINE CONNECTION end 


<ESC>Oo 


external call indication on/off (toggle) 


<ESOOp 


MOBITEX, start sending message 


<ESOOq 


increase volume 


^ESOOr 


decrease volume 


<ESO0s 


loudspeaker on/off 


<ESC>0t 


cancel 


<ESC>Ou 


TELEPHONE 


<ESC>0v 


scroll up presentation field 


<ESC>0w 


scroll down presentation field 


<ESC>0x 


get next message 


<ESC>0y 




<ESO0z • 




<ESO0{ 




<ESC>0] 




<ESC>0} 





When the terminal is sending- the character DEL (decimal 127) is 
interpreted as the terminal wishing to remove the character to 
the left of the cursor. 
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3.5 PROTOCOL FOR "MASC" TYPE TERMINALS 

The raasc type interface is designed for connection of units 
with the capacity to handle complete data packets (MPAK see 
reference Rl-09), e.g. a personal computer. Information is 
transferred between the terminal and MCU in the form of frames, 
described in subsequent clauses. Control of the complete mobile 
terminal, e.g. audio equipment and manual mode, is performed by 
special commands included* in the protocol. The interface also 
contains functions for reading status parameters in the mobile 
terminal (meant for the type test). 

For type testing, a raasc type interface is" required. In this 
case it may be implemented by external adaptors. For the type 
testing, only the basic commands and the type testing commands 
are required. 

A frame is formed as a message packet with unique characters 
marking the beginning and the end of the frame. Sending may be 
initiated from both sides. The information frame must be 
acknowledged with ACK before the next information frame -is 
sent. 

The characteristics of the protocol are: ' 

- All characters are coded into the 7 least significant bits 
and bit 8 is used for even parity. 

- The error control is done by longitudinal and character 
parity check and frame length control, 

- Transparent data can be sent in hex coded data fields. 

- The protocol permits full duplex. 

3.5.1 Frame structure 



Communication takes place in the form of frames. There are two 
types of frames, information frames and control frames. The 
information frames are used to transfer commands and other 
information. The control frames are used to control the ■ 
information frame flow. 
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The Information frames are divided into the following fields 
(number of octets stated -below) : 




1 start] length) text jstd.j 


data | check j end j 




1 4 1-2S6 1 


0-1120 2 1 




The Control frames are divided into the following fields 
(number of octets seated below): 




1 start) type) sequ (end | 






110-11 






The maximum frame size permitted is set up by the B-command. 
The maximum possible size is 1150 octets. This means that an 
Information frame can not have the maximum length in all 
fields. _ 




- Start 






The start of a frame is denoted by the character 2. with code 
136/94/5E in octal/decimal/hexadecimal notation. 




All characters received before 
ignored. Every start character 


the start character should be 
is the beginning of a new. frame. 




- Length 






The size of the frame, in number of octets, should be written 
in this field with the ASCII codes of four hexadecimal digits. 
The least significant digit should always be written in octet 
4. 




The size of the frame includes all octets including start and 
end characters. 

Permitted characters of length field: 0-9, A-F. 




- Text 






Text is a field which determines the meaning and the 
interpretation of the frame. The interpretation of the text 
field is carried out by a higher layer. The text field consists 
of at least 1 character and a maximum of 256 characters. 
Numeric information, e.g. command parameters, are always to be 
-given as the ASCII codes of the corresponding hexadecimal 
digits 0-P. 

Permitted characters of text field are: 

SPACE (40/32/20) to } (175/125/7D) except Std(:) and 

startcharacter(") . 
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- Std (start data) 






Text and data are separated by the character : (colon 
72/58/3A). Std should be seated even if the data field is 
empty. 




- Data 






The data field consists of data. 

The coding of the data field is carried out in hexadecimal code 
so that transparent data can be sent. Each octet of data which 
is to be coded into the data field is divided into two half 
octets with four bits- in each. Each of these four bit groups is 
then represented in the data field by the ASCII code of the 
corresponding hexadecimal digit 0-F. Thus each input. octet is 
represented by two characters (octets) in the data field. 




The data field consists of maximum 1120 characters. 
Permitted characters of data field is: 0-9, A-F. 




- Check 






Longitudinal checksum created by exclusive OR on all characters 
starting with the start character and ending with the character 
before the checkfield. The check field consists of two ASCII 
coded hexadecimal digits with the least significant digit in 
octet 2. 




Permitted characters for the check field is: 0-9, A-F 




- Type 






The type of control frame is stated with one character. The 
characters which may be used are * (52/42/2A), ? (77/63/3F), 
! (41/33/21), # (43/35/23) or & (46/38/26). 




- Sequ (sequence number) 






The sequence number for ACK-frames. The sequence number can be 
one of the characters 0 (60/48/30), 1 (61/49/31) or - (minus, 
55/45/2D). 




- End 






The frame is terminated with the carriage return character (CR, 
15/13/OD). A frame which is not ended with the end character 
should be ignored. 


Siprod 
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3.5.2 Information frame 

Messages are sent as Information frames with an expected 
acknowledgement (ACK). 

The text field of an Information frame has che following 
general structure: 



com SP I par 



>=1 0-1 >=0 

com is the command or function code. 

SP is the space character (ASCII code 40/32/20 in 

octal/decimal/hexadecimal notation) which separates the 
command from the parameters. 

par is the ASCII coded parameters or data. 

A command which sets parameter A to 587 can be coded in the 
following ways (all commands are terminated with CR) : 

~0010S A=S87:50 
"0012SET A/587 :D1 

~0010S A:028BAF 028B is hex code for 587 

"000FSA:028B78 SA is a command 



Note: The textfield can only consist of one (1) command. 
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3.5.3 Control frames 

The protocol consist of the following control frames: 



- ACK 

- NACK 

- RACK 



- ACK (Acknowledgement of a correct received frame) 
Structure: 



1*|* ['sequ | CR | 

1111 

ACK means that the received Information frame is correct. A' 
correct frame should comply with the following: 

- starts with the start character {*) 

- contains only one colon ( : ) 

- the fields "check" and "length" have the correct values 

- only permitted characters in text and data fields 

- no characters with parity error 

- the permitted number of characters has not been exceeded in 
any individual field or in the complete frame. 

- ends with the end character (CR) 

The field "sequ" (sequence number) should alter between ASCII 
character 0 and ASCII character 1 for each frame sent, except 
when repeating the latest ACK on a RACK request. Then the same 
value as before is sent again. 

The first time an ACK is sent "sequ" should be the character 0. 
If a RACK is received before any ACK has been sent, the field 
"sequ" will be filled with the character - (minus). "Sequ" with 
the value of - (minus) is only, used when RACK is received 
before ACK has been sent the first time. 



- NftCK (No acknowledgement of an incorrect received frame) 
Structure: 



111 

NACK is to be sent if the conditions for sending ACK are not 
fulfilled and the Information frame: 

- starts with the start character (") 

- contains only one colon ( : ) 

- has a total length of 10 characters or more 

- ends with the end character (CR) 
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Should the criteria not be fulfilled for sending ACK or NACK, 
no reply will be given. The frame will then be repeated by the 
timeout function in the sending unit. 

If the receiving unit cannot handle the incoming data flow, 
NACK may be used to limit the flow. 

- HACK (Request for repetition of the latest sent ACK). 
Structure: 



RACK, request for repetition of the latest sent ACK, is sent 
when no reply on the Information frame has been received within 
10 seconds. The receiver of RACK is to reply by repeating ACK 
with the latest sequence number (sequ) used. 

- SENS (link layer control) ._. ... 

Structure: • . 



SENS is used to control the communication link when there is no 
traffic. The sender decides when SENS will be sent. Time • 
between 2 SENS should be at least 10 seconds. 

When sending a SENS a reply (SACK) will be received within 10 
seconds. If no reply is received within 10 seconds, a hew SENS 
will be sent. When two SENS have been sent and no reply is 
received or no info-frame has been correctly transmitted, the 
communication link is supposed to be broken. A restart will be 
done by sending a B-frame. 

If SACK is received and no SENS has been sent, the SACK will be 
ignored. 

- SACK (Sens acknowledgement) 
Structure: 



SACK will be sent when a controlframe (SENS) has been received. 
It should be sent at the first possible opportunity when 
nothing else is being sent. 
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3.5.4 Flow control and error handling 

If the reply of an Information frame is ACK, the Information 
frame will be correctly .received. The field "sequ" is saved as 
the latest received sequ number. 

If the reply is a MACK , the Information frame will be repeated. 

If there is no reoly within 10 seconds after the Information 
frame was sent, a" BACK will be sent. If there is no reply on 
the HACK, a new HACK will be sent every 10 seconds. If no ACK 
has been received within 30 seconds after the Information frame 
was sent (time-out), higher layers will be notified. However, 
the repetition of RACK will continue until interrupted by 
higher layers or by the fact that an ACK has been received. 

When an ACK is received as a reply to a RACK, the sequ number 
of this ACK will be compared with the stored sequ number of 
latest received ACK. If the numbers are equal, the Information 
frame was not received and must be repeated. If the numbers are. 
different, the Information frame was received correctly (but 
ACK was lost) and the Information frame should not be repeated. 
However, if the sequ number of the. received ACK is - (minus) 
the Information frame must be repeated. 

When the physical layer gets into datatransraission mode the 
link layer is supposed to start up. 

When one of the two interconnected units is started up, it has 
no stored value of the sequ of the latest received ACK. Neither 
does it have a value of the sequ of the latest sent ACK. To 
handle this situation and to prevent a possible doubling of the 
first frame, the following start up procedure is required: 

- The first Information frame sent should be a B-frame. This 
B-frame consists of communication parameters for raasc 
protocol (see appendix A). 

- If the sending of that B-frame leads to error handling with 
RACK, the B-frame must be repeated regardless of the value 
of the sequ field of - the ACK response to RACK. 

The actions to be taken when receiving ACK as a response to 
RACK are summarized in the following table: 

sequ of 









received ACK 










0 


1 




sequ 


none 


repeat 


repeat 


repeat 




of the 






repeat 






latest 


0 


repeat 


no rep. 




received 












ACK 


1 


repeat 


no rep. 


repeat 
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Conaaunication is on a full duplex line. This means that a 
message stream can be in .progress in both directions at the 
same time. Both parties may send an Information frame 
independently of each other and an Information frame may 
therefore be received when a control frame is expected 
(ACK/NACK). However, the next incoming frame will then be a 
reply as each Information frame is to be acknowledged before a 
new one is sent. The minimum time between these two frames will 
be the time set by the ' int {interval) parameter of the 3- 
coramand (minimum time between the sending of two subsequent 
frames ) . 
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3.5.5 Time diagram 








0. MCU/ terminal starts up by setting protocol parameters. 

1. MCU sends Information frame 0 to terminal which sends 
acknowledge • 

.2. MCU sends Information frame 1 which is disturbed and then 
repeated after NACK from terminal. 

3.0 MCU sends Information frame 2 but it does not reach che 
terminal the first time. Information frame repeated after 
HACK and repeated ACK being the same as previous ACK 
(sequ=0). 

3.1 The same as 3.0 but this time ACK[1) dpes not reach the 
sender. RACK is sent and now the repeated ACK, having a new 
sequ, indicates that the frame was received correctly. 

4. MCU and terminal sending Information frames at the same 
time. 

5. MCU and terminal doesn't start at the same time. 
5.5 MCU restarts and B-frame is repeated. 






(Number in brackets after ACK denotes sequence number) 




MCU 


raasc 


protocol 


operator terminal 




0. B(len,int) 








— > 


ACK{0) 








B(len,int) 




ACK(O) 
1. Info frame 0 


















ACK(l) 




.2. Info frame 1 










X > 


NACK 




Info frame 1 






ACK(0) 




3.0 Info frame 2 
timeout 10 s 
RACK 




> 










ACK(0) 




info frame 2 


< 








ACK(l) 












3.1 Info frame 2 

timeout 10 s 
RACK 












ACK(l) 




> 


ACK(l) 
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MCO 



operator terminal 



4. Info frame 3 
time>=int 
ACK(l) 



C 



5. start of MCU 
B<len,int) 
timeout 10 s 
I RACK 



ACK(O) 
^-timeout LQ,-s 
RACK 



5.5 start of MCO 
B(len,int) 

timeout 10 s 
RACK 



Ir.fo frante 4 
ACK(O) 



start of op. ten 
B(len,int) 



ACK(-) 
ACK{0') 
working 
ACK(O) 



ACK{0) 
ACK(l) 
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This interface is intended for the connection of audio 
equipment such as microphone and loudspeaker or a handset. The 
interface also contains certain control functions. 

A simple audio equioment can consist, of a loudspeaker and a 
microphone or a handset with holder and switches so activate 
the functions needed (hook on/off, push-co-caik) . The nandset 
can also be a more comolex uni = using serial data to _ 
communicate over che interface and including a small display 
and numeric and status keys. Some examples, are given in 
application examples. 



4.1 PHYSICAL INTERFACE 

The terminal interface uses a 15-pole DSUB socket (female 
socket with pins) with the following configuration: 



PIN 


SIGNAL 


ACTIVE 


SOURCE 


1 
2 
3 

' 4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 


ground for earphone/loudsp 
data send 
data receive 

extern, call indie, on/off 
volume up 
volume down 

ground for control signals 

system start 

+12V 

-12V 

microphone LP 
microphone ground 
microphone hook on/off 
transmit/receive switch 
earphone/loudspeaker LF 


on = 0V 
up = OV 
down=0V 

start=0V 

lifted=0V 
t.ransm.=0V 


MCU 

audio equipment 
MCU 

audio equipment 
audio equipment 
audio eauipment 
MCU 

audio equipment 

MCU 

MCU 

audio equipment 

audio equipment 
audio equipment 
MCU 



pins: 



Data send/receive 

V24/V28 applies. „ 

Data is formatted in accordance with "terminal with 

small display". 

Exter nal call indication on/off 

When pin 4 is activated, MCU toggles the external 
call indication on/off. When on, the external call 
indicator (e.g. horn) is activated when a message is 
received. 
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pins: 

5,6 Volume up/down . 

Grounding pin 5 or 6 will adjust ths audio level- 
volume) of the loudspeaker or the earphone, 
whichever is active when the pin is activated. (The 
audio level of the inactive unit will remain as 
before.) The adjustment is made in steps, one step 
for each new activation of the pin. If the pin is 
activated continuously, the level to be adjusted by 
one step per second. The lowest level possible to 
set muse still be noticeable. 

8 System start 

MCU will' start up within 10 seconds when pin 8 is 
activated, it then remains on until switched off by 
other means even if the pin is inactivated. 

9,10 Power supply of connected equipment 

+12V (pin 9) is able of supply a current of at least 
500 raA and -12V (pin 10) a current of at least 100 
raA. - 

11,12 Microphone input 

Input impedance: 10 kohm. 

Sensitivity: .An input signal with the frequency 
1 kHz and a level of 100 mV produces an RF deviation 
of 3.0 kHz. This level is produced by the microphone 
at a sound pressure of 94 dB above 2*10 pascal. 

13 Microphone hook on/off 

When the microphone or handset is lifted from its 
holder, pin 13 is activated (HOOK_OFF signal 
generated}. If a handset with earphone is used, the 
loudspeaker will be inactivated and the earphone 
activated. When the microphone or handset is placed 
in its holder again, pin 13 will be inactiveted 
(HOOK_ON signal generated). If an earphone has been 
used, it will be inactivated and the loudspeaker 
activated (for audio level settings, see pin 5,6). 

14 Transmit/receive switch 

When activated, the radio unit will transmit and 
when deactivated, the radio unit will receive (push- 
to-talk switch). 

1,15 Earphone/loudspeaker 

This output is able to support impedances down to 4 
ohms. 

Earphone sensitivity: The earphone produces a sound 
pressure of 85-95 dB above 2*10 pascal when driven 
by a signal with the frequency 1 kHz and a level 
corresponding to an RF deviation of 3.0 kHz. 
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5.1 PHYSICAL INTERFACE 

The terminal interface uses a 15-pole DSDB socket (female 
socket with pins) with the following configuration: 



PIN 


SIGNAL 


ACTIVE 


SOURCE 


1 


emergency 1 


emerg=0V 


emergency 


equip. 


2 


emergency ACK 


ACK =0V. 


MCO 




3 


eraergency_ack. from fixed 


emack=0V 


MCU 




4 

5 


emergency~ack. ACK 


ACK =0V 


emergency 


equip. 


6 


emergency 2 


emerg=0V 


emergency 


equip. 


7 


ground for control signal 








8 


system start 


start=0V 


emergency 


equip. 


9 


+12V (supply) 




MCU 




10 


* 








11 


emergency 3 


emerg=0V 


"emergency 


equip . 


12 


emergency 4 


emerg=0V . 


emergency 


equip. 


13 


emergency LF input 




emergency 


equip. 


14 


emergency LF ground. 




emergency 


equip. 


15 


external indicator 


on = 0V 


MCU 





Emergency 1 

Emergency alarm from an external emergency unit, 
e.g. a receiver for emergencies sent on radio from a 
pocket transmitter. Emergency 1 (pin 1) is used 
together with pin 8 (system start) and pin 2 
(emergency ACK from MCU) to be able to initiate an 
emergency alarm even if MCU is powered off. When the 
external emergency unit' initiates the alarm, it 
activates both pin 1 (emergency 1) and pin 8 (system 
start). After detecting the alarm, MCU sends an 
acknowledge to the emergency unit by activating pin 
2 (emergency ACK from MCU). The emergency unit must 
keep pins 1 and 8 activated until this ACK has been 
received. 

MCU will then create and send a SOS packet to the 
network. 

Emergency ACK from MCU 

Emergency ACK is an acknowledgement from MCU that 
emergency 1 has been received by MCU (response to 
■ activation of pin 1). 
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Emergency acknowledgement from fixed terminal 
When the fixed terminal has received the emergency 
message (SOSINFO), it can send a special emergency 
acknowledge packet (SOSACK) or a request for an 
emergency connection (SOSCONREQ) addressed to the 
alarming" subscription. When a SOSACK is received by 
MCD, it indicates this co the emergency unit by 
grounding pin 3. The emergency unit in turn grounds 
pin 4 as an acknowledgement. 

Additional reactions from MCD when receiving SOSACK 
or SOSCONaSQ are very much depending on application. 
A parameter emergency-acknowledge-status should be 
implemented and stating at least the following: 
status = 0 no additional reaction 

1 activate external indication (e.g. horn) 

2 emergency line connection in direction 
mobile to base (one-way, mobile 
transmitting) 

3 send acknowledge to op. terminal 

Emergency acknowledgement ACK from emergency unit 
Used by the emergency unit to acknowledge the 
activation from MCD of pin 3. 

Emergency 2, 3 and 4 

These pins are intended for initiating an emergency 
alarm from simple emergency equipment such as a 
single push button. When one of these pins is 
activated, MCU creates a SOS packet and sends it to 
the network. Should the pin remain active, the time 
between repeated SOS packets must be at least 1 
minute. The signals are not acknowledged by MCU. 

System start 

MCU will start up within 10 seconds when pin 8 is 
activated. It then' remains on until switched off by 
other means even if the pin is inactivated. 

Power supply for external equipment 

+12V is able to supply a current of at least 500 raA. 

(The emergency unit should always be powered up) 

Emergency LF input- (for emergency connection) 
Input impedance: 10 kohra. 

Sensitivity: An input signal with the frequency 
1 kHz and a level of 100 mV produces an RF deviation 
of 3.0 kHz. This level is produced by the microphone 
at a sound pressure of 94 dB above 2*10 pascal. 

- Activation of external indicator 
This pin is used to activate an external indicator 
(e.g. horn). It is able to sink at least- 100 mA to 
operate e.g. a relay which activates the horn (open 
collector output). 
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Time diagram; 

UNIT (emergency 1); 



packet 


radio path 


RADIO/HCU 


interface 


em. unit 


SOS 




. start 
emergency 1 
emergency ACK 
send emergency signal 
(external indicator 
might be activated 


< 8 

< l 
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15 > 


start up 
emerg. 1 
ack 
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IN CASE OP MANUAL ACKNOWLEDGE FROM FIXED TERMINAL AFTER 
RECEIVING SOS INFO 



emerg. _ack from fixed 



acc. to em. ack. status 
(■e.g. ext. indicator 



fixd ack 
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EMERGENCY BOTTOM (emergency 2, 3 or 4): 



packet 


radio path 
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interface 
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(e.g. ext. indicator 
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6 APPLICATION EXAMPLES 

The interfaces can be used in a variety of ways depending on 
the application. Below are some examples given. 

The terminal equipment can be connected to these interfaces. 

OP. 

terminal interface 
plug 

~ The op. terminal comprises a 

display for- message presen- 
tation and editing and a 
keyboard for entering 
mands and information - 



printer interface 
plug 



25pin 



Printer for printing out 
text or data collection 
unit sending text strings. 



audio interface 
plug 



15pin 



AUDIO EQUIPMENT 

Loudspeaker and microphone 
Or handset with or without 
keys. 

Switches/buttons to control 
interface signals and/or 
serial data according to 
V24/V28. 



emergency interface 
plug 



Emergency unit, e.g. receiver 
for emergencies from pocket 
transmitter, or simple 
emergency buttons to initiate 
emergency signal (SOS) from 
MCO. 
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The following examples are described: 

1. Microphone/loudspeaker 

2. Handset with numeric and function keys 

3. Handset with numeric and function keys, printer 

4. Microphone/loudspeaker, control unit, printer . 

5. Op. terminal with small display, loudspeaker, printer 

6. Op. terminal of ANSI type, microphone/loudspeaker, data 

collection unit 

7. PC, microphone/loudspeaker 

8. PC, handset with keys, printer, emergency equipment 

9. PC, microphone/loudspeaker, control unit, printer, 

emergency equipment 

(PIT = push-to-talk button) 



1. Microphone/loudspeaker 



A*audio interface 



Is able to send/receive speech. (Sends only to default 
receiver) 



2. Handset with numeric and function keys 



3 

■3 



H=earphone 

A=audio interface 
M=microphone 



Is able to" send/receive status and speech. 
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3. Handset with numeric and function keys, printer 



0 § 



H= earphone 

A=audio interface 
M=micro'phone 



- j PRINTER | TP=term. inter f. 

printer 

Is able to send/receive status and speech and to receive text. 
4. Microphone/loudspeaker, "control unit, printer 



IPTT 



LOUDSP 
~ 1 



A=audio interface 



PRINTER TP=term. interf. 
1 printer 



Is able to send/receive status and speech and to receive text. 
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5. Op. terminal with small display, microphone/loudspeaker, 
printer 



A=audio interface 



-j OP-T ERMINAL | TD=term . inter f. 
L — small display 



PRINTER j TP=term. interf. 
printer 



Is able to send/receive text, status and speech. 



6. Op. terminal of ANSI type, microphone/loudspeaker, data 
collection unit. 



MIC "IPTT LOUDSP 



A=audio interface 



j DAT A COLL. | TP=term. interf. 

1 printer 

Is able to send/receive text, data, status and speech. Data can 
be controlled and collected over radio in the form of text 
strings to and from the data collection unit. 
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7. Personal computer as terminal, microphone/loudspeaker 



LOCDSP 



_j 



PC 



A=audio interface 
TM=term. interf. 



Is able to send/receive text, data, status and speech. 

8. Personal computer as terminal, handset with numeric and 
function keys, printer, emergency equipment " 



A=audio interface 



TH=term. interf. 
■masc' 



. PRINTER TP=term. interf. 



TEMERG. EM=emergency interf 



Is able to send/receive text,, data, status, speech and 
emergency. 



Exhibit 2, p. 748 



36 **" 


Cantel Mobitex- 


»s 1 1 1 

10S6 - A 296 5175/3 Qe 


1990-02-23 A j MTS19.3 



9. Per sonal computer as terminal, microphone/loudspeaker, 
control unit, printer, emergency equipment ~ 



A=audio inter f. 



PRINTER | TP=term. interf. 
printer 



EMERGENCY | EM=emerg. interf r 



Is able to send/receive text, data, status, speech and 
emergency. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 16 



Below are the reference designations listed. 



Reference Section 

Rl-01 .. Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 
Rl-04 ... Terminology 

Rl-05 References """" 

Rl-0£ Network operator information 

Rl-08 Application layer 

Rl-09 ■ Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Ri-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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MOBITEX Terminal Specification 
Mobitex ASyncronous Communication 
APPENDIX A, Commands 



This, document specif ies commands in the interface MOBITEX 
ASyncronous Communication (MASC) used between an 
application and a mobile terminal. 



AJ3JS1KW 
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TABLE OF CONTESTS 



1 INFORMATION FRAME COMMANDS AND FUNCTIONS IN MOBILE 
TERMINAL 5 

1.1 BASIC FUNCTIONS 5 

1 . 2 TYPE TEST FUNCTIONS . . 6 

1.3 TERMINAL SYSTEM FUNCTIONS ' 7 

1.4 AUDIO FUNCTIONS ' ; 7 

1.5 MANUAL RADIO FUNCTIONS 7 

1.6' USER COMMANDS 7 

2 BASIC FUNCTIONS (always to be implemented in MCU) ... 8 

2.1 B-command (parameters for the MASC protocol) 8 

2.2 M-command (send/receive MPAK via radio) 9 

2.3 E-command (Error command or function) ..10 

2.4 N-command (return of MPAK not sent) 11 

2.5 R-command (return of incorrect MPAK) 12 

2.6 D-command (route received MPAKs to an output) ....13 

2.7 S-command- (sends MPAK to the specified output) ..".15 

2.8 T-command (request/transfer of emergency text). ..16 

2.9 U-command (send emergency signal SOS) 17 

2.10 F P-command (MAN request) , 18 

2.11 F Q-command (device handling the MASC protocol) ..IB 

2.12 F F-coramand (MCU in contact with mobitex) 18 

2.13 F G-coramand (MCU not in contact with mobitex) ....18 

2.14 F H-command (MPAK sent over radio path) 18 

2.15 F K-comraand (error message from MCU) 18 

2.16 F O-command (prepare to close down) .18 

2.17 F #-command (short number list) 18 

3 TYPE TEST FUNCTIONS (always to be implemented in MCU) 19 

3.1 P-command (request/list of parameters) 19 

3.2 PA-comraand (request/list of radio-parameters) ....20 

3.3 PA-command (request/list of identity-parameters) .22 

3.4 PA-command (request/list of channel -parameters ) ..23 

3.5 PA-comraand (request/list of roaming-parameters) ..24 

3.6 PA-command (request/list of test-parameters) 25 

3.7 K-command (receive/transmit frequency number) 27 

3.8 KA-comraand (receive/transmit frequency number) ...28 

4 TERMINAL SYSTEM FUNCTIONS (implemented according to 
application) ....29 

4.1 F B Change to MOBITEX operation mode *.i 29 

•4.2 F C Set up a MOBITEX line connection 29 

4.3 F D Set up a TELEPHONE line connection 29 

4.4 F E Disconnect line connection 29 

4.5 F F Contact with the MOBITEX network 29 

4.6 F G No contact with MOBITEX network : .29 
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4.7 F H MPAK sent by the radio to the network 30 

4.8 F I Cancell previously transmission of; MPAK ....30 

4.9 F J Print out current MANs in terminal 30 

4.10 F K Error message about a fault situation .-. 30 

4.11 F L Activate external call indicacion 30 

4.12 F M Transmitter on/off 30 

4.13 FN Change to MANUAL RADIO mode 30 

4.14 F 0 Prepare for closing down MCO 30 

4.15 • F P Terminal MAN request/answer 31 

4.16 F Q MASC device identity 31 

4.17 F R Change network identification .31 

4.18 F S Change AREA-LIST 31 

4.19 F T. Change TEMP_DEF AOLT_L 1ST 31 

4.20 F V Speech queue information 32 

4.21 F * Short number list 32 

5 AODIO FUNCTIONS (implemented according to 
application) 33 

5.1 A B Increase audio volume level 33 

5*2.-.. A C . ..Decrease audio volume level 33 

5.3 AD Loudspeaker on/off r ....33 

5.4 A E External call indication on/off 33 

'5.5 AH Microphone (hook) on/off 33 

5.6 A T Transmit/receive switch 33 

5.7 A J Hands free 33 

5.8 AV Audio level order 33 

6 MANUAL RADIO MODE FUNCTIONS (implemented according to 
application) "34 

6.1 HA Change to MOBITEX mode 34 

6.2 H 3 Increase audio volume level 34 

6.3 H C Decrease audio volume level 34 

6.4 H D Loudspeaker on/off 34 

6.5 HE External call indication on/off 34 

6.6 H F Call indication 34 

6.7 HG Squelch open/closed (toggle) 34 

6. a H H Microphone (hook) on/off 34 

6.9 HI Transmit/receive switch 34 

6.10 H J Hands free 35 

6.11 H K Change to channel number 35 

6.12 H L Channel number indication 35 

6.13 H M Send selective call number 35 

6.14 H N Scan the specified channels 35 

6.15 HO Carrier indication 35 

6.16 HP Copy of own selective number 35 

6.17 HQ Transmit/receive indicator 35 

7 Signalling between MCO and terminal equipment 
connected to the MASC interface ...37 

7.1 MPAK received from the network 37 

7.2 MPAK received from a terminal 38 

7.3 Connection between the MCU and the terminal 39 

7.4 Signalling between MCO and more than one- terminal 40 
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7.5 Description of a system with MASC interface. ...41 

7.6 Fault situation in mobitex mobile stations .45 

8 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 47 



Exhibit 2, p. 754 



Cantel Mobitex - 


'2/1056 -' A 296 5175/2 Ue 


T990-02-26 ' A ) >_ "mTS19A.2 


1 INFORMATION FRAME COMMANDS 


AND FUNCTIONS IN MOBILE TERMINAL ■ 



The commands, questions arid reolies available as information 
frames in MASC are summarized below and a description is given 
on the following pages. 

1.1 BASIC FUNCTIONS 

The following commands are always to be implemented in MCU. 



3 parameters for the MASC protocol 

M send/receive MPAK via radio 

E error command or function 

N return of MPAK that has not been sent 

R return of incorrect MPAK 

D route received MPAKs to an output 

S send MPAK to the specified output 

T request or transfer of emergency text 

U send emergency signal (SOS-packet) 

F p terminal subscription MAN request and answer 

F Q device handling the MASC protocol 

F F MCU in contact with Mobitex network 

F 6 MCU has no contact with Mobitex network 

F H MCU inform that MPAK has been sent over the radio 

F K Error message from MCU 

F 0 Prepare to close down MCU 

F # Short number list request and answer 
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1.2 TYPE TEST FUNCTIONS 

The following commands are always to be implemented in MCU. 

These functions should only be used during type testing and must 
be made inoperative for normal use. 

All requested parameters which are available in the mobile 
should be included in all answers co type test functions. 

Type test functions consist of commands belonging to specific 
radio protocol. 

To separate mobile terminals with different radio protocol, the 
following commands are available: 

P-coramand Used in mobile terminal at 1200bps. 

K-command Used in mobile terminal at 1200bps. 

PA-coramand Used in mobile terminal at 8/16kbps. 

KA-command Used in mobile terminal at 8/16bps. 
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1.3 TERMINAL SYSTEM FUNCTIONS 

The following commands to be implemented in MCU, according to 
application. 

F system control 



1.4 AUDIO FUNCTIONS 

The following commands to be implemented in MCtJ, according to. 
application. 

A controlling audio functions 



1.5 MANUAL RADIO FUNCTIONS 



The following commands to be implemented in HCU, according to 
application. 



controlling manual radio mode 



1.6 USER COMMANDS 

The following commands are free to use in applications.- 
If used in application, contact mobile raanufactor about 
implementation in MCU. 
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2 BASIC FUNCTIONS (always to be implemented in MCU) 

2 ' 1 B-command (parameters for the MASC protocol) 
Structure of text field: 



1 B }• SP | len j , 1 int | 

11 3 11-4 
The data field is empty. 

The B-command is used to set parameters for the protocol. 

len is a 3-digit ASCII coded hex number which sets the maximum 
length of an Information frame. This field should always be set 
to the maximum possible frame size, i.e. 47E (1150 decimal). 

int is a maximum 4-digit ASCII coded hex number which sets the 
shortest time between two subsequent frames. The value is given 
m 10 ms increments. Default value is int =0. 

len and int are separated by a , ( comma ). 

These parameters should be used as soon as they have been 
received. 

' The default values are used until a B-command has been received. 
A B-command should be the first frame sent after start up. 

After receiving a B-command, the protocol should send a 
start_of_line signal to a higher protocol, to make clear that 
the connection is established and that the start sequence can 
follow. 

Start_of_line signal is an internal signal between the link 
layer and higher layer. 
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2.2 H-commaad (send/receive MPAK via radio) 
Structure of text field: 



M j SP | ssqu-id 



SP indicate that a sequence number identity is added. If no SP 
then there is no sequ-id. 

sequ-id is a 1-digit ASCII coded decimal number between 0-9. 
This sequence number is an identity of the MPAK. 

Structure of data field: 



[_ ^ _ MPAK ' J 

16-1120 

MOT receiving the M-command sends MPAK via the radio path to the 
network. If M-command consists of a sequence number, the command 
PH indicating 'sent to mobitex network' is sent to terminal 
including the sequence number. Returned MPAK should also 
indicate sequence number. 

MPAK received via the radio path, is sent over the interface to 
the terminal with the M-command (MAN is included in MPAK) . The 
sequence number is not used in this M-command. ' 



The received MPAK ( to be sent via the radio path) should be a 
permitted MPAK concerning valid information in the MPAK head and 
MPAK length (sender, traf state, class, packet type, size of 
MPAK). 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.3 E-command (Error command or function) 
Structure of text field: 



The datafield may be used to send information about =he error. 

The E-coramand informs that the previously received command or 
function cannot be executed. (Command or function is noc 
implemented in the receiving unit or included parameters are not 
accepted) . 



A232515M 
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2.4 N-command (return of MPAK not sent) 
Structure of text field: 

1 N ! SP j err-code j , | sequ-id j 

112 11 
SP indicate that an error code and sequence number are added. If 
no SP then there is no error code or sequence number. 

err-code is a 2-digit ASCII coded hex number between 00 - FF. 
This error code is described in chapter "Fault situation in 
raobitex mobile stations". 

vid is a 1-digit ASCII coded decimal number between 0-9. 



sequ- 
This" 



sequence number is an identity of the MPAK. 
Structure of data field: 



L _ _ ! 

16-1120 

The N-command indicates to the terminal that the MPAK has not 
been sent over radio (communication failure or transmission 
interrupted by FO or Fl-command). 

In manual mode MPAK's should be returned by the N-command. 

The MCD can indicate the reason, of not sending the MPAK over 
the radio, by adding the error code. 

If a sequence number is indicated in the M-comraand, then this 
sequence number should also be in the N-frame. 

If no error code or sequence number is valid, this pararameter 
is not added. 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.5 fr-command (return of incorrect MPAK) 

When receiving the R-frarae and not finding the fault, the 
receiving unit is supposed to make a restart by sending a B- 
frame. 

Structure of text field: 



j sequ-id i 



SP indicate that an error code and sequence number are added. If 
no SP then there is no error code or sequence number. 

err-code is a 2-digit ASCII coded hex number between 00 - FF. 
This error code is described in chapter "Fault situation in 
mobitex mobile stations". 

-id is a 1-digit ASCII coded decimal number between 0-9. 



This sequence number is an identity of the MPAK. 
Structure of data field: 



16-1120 



MCD uses the R-frame to return an MPAK which was received with 
the M-command and which does not coraoly with the format and the 
rules set by the network and link layers of MOBITEX terminals. 

The MCO can indicate the reason, of not accepting the MPAK, by 
adding the error code. 

If a sequence number is indicated in the M-command, then this 
sequence number should also be in the N-frame. 

If no error code or sequence number is valid, this pararameter 
is not added. 



Description of the different MPAKs can be found in 1 
layer for terminals", see reference Rl-09. 
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2.6 D-command (route received MPAKs to an output) 
Structure of text field: 



I D I SP j MAN I , i 3TG I , j TYP | , } SET | 
1 16 111111 

The data field is empty. 

MAN is a 6-digit ASCII coded hex number stating the MAN for 
which MPAKs are to be routed to output OTG. MAN must be one of 
the possible MANs of the terminal (terminal MAN, group MAN or 
personal MAN] . 

UTG is a 1-digit ASCII-coded hex-number stating the output to 
which received MPAKs are to be routed. 

TYP is a 1-digit ASCII-coded hex-number stating the type of MPAK 
which is to be routed to OTG. _ 

SET is activating the function of set/reset these parameters. 
DTG and TYP to be used as follows: 

OTG = o default output 

1 printer 

2 audio 

3 emergency 

4 op. terminal:! (MASC protocol) 

5 op. terminal: 2 

6 op. terminal: 3 

7 op. terminal: 4 

8 op. terminal :S 

9 op. terminals 

TYP — 0 no types(reset all) 

1 text 

2 data 

3 status 

4 line connection (speech) 

5 emergency ■ 

6 all types except emergency 

7 extpak 

8 hpdata 

9 dteserv 

SET = 0 set these parameters 

1 reset these parameters . 
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After receiving the D-command, MCU will route incoming MPAKs of 
the specified type and intended for the specified MAN to the 
function block which handles the communication (formatting etc) 
for the specified output.. Thus it is possible to route MPAKs to 
several outputs e.g. to both printer and op. terminal. 

When receiving a D-command with UTG="default output", 'the MCU 
resets all earlier D-commands for the SDecified MAN and 
specified TYP. If for example the ?YP is "all types", all 
earlier D-commands concerning this specified MAN are reset and 
all types are sent to default output" connection. If TYP is "no 
types", then all types is reset for this MAN and OTG. 

It is possible to set or reset an earlier D-command, using the 
parameter set or reset. 

After logout, a personal subscription should be removed from 
this list of routing. MPAKs. 

When power on, MCU sets up default outputs, e.g. text, data and 
status.ta op. terminal- and line connection to audio interface. 

All MP AK : DTES ERV is routed to output, where terminal MAN is 
located(can be more than one). 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.7 S-command (sends MPAK to the soecified output) 




Structure of text field: 






| S | SP 1 OTG | 






11 1 






Structure of data field: 






[ MPAK 






16-1120 






OTG is a 1-digit ASCII-coded hex-number which states to which 
output MPAK is to be -sent. 


.... 


When receiving the S-command, MCU sends MPAK to the output 

s fcafeed-_fey UTG • ■ • • ■ .. ■ . , T .- ■ • +. 




The parameter OTG is to be used as follows: 




OTG = 0 direct to default output 

1 printer 

2 audio 

3 emergency 

4 op. terminals (MASC protocol) 

5 op. terminal: 2 

6 op. terminal: 3 

7 op. terminal: 4 

8 op. terminal: 5 

9 op. terminal: 6 
A 

B 
C 
0 




E - 

P printer, without printing the MPAK-head 




Nate 1: When the parameter UTG = F, the datafield consists of 

printable information except the MPAK-head. The printer 
should ignore the MPAK-head, this means that the 
information starts in octet 12. 




Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 





















ASM.H3M 
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2.8 T-command (request/transfer of emergency text). 
Structure of text field, request: 

m 

i 

Structure of data field for transfer of emergency rext: 



Emergency text 
0 - 2S6 



The T-command is used by the terminal to set up in MCD the 
dynamic text part of the emergency signal and as a request to. 
MCD to return the stored emergency text. MCD uses the command as 
a reply to the request. 

The emergency text field is the emergency text which is to be 
transferred. The emergency text can have up to 256 characters 
according to MOBITEX textcode. The first two octets of the text 
part are reserved to indicate the source of the emergency. 

Source of emergency: Emergency 1 - 01 
Emergency 2 = 02 
Emergency 3 = 03 
Emergency 4 =04 
Handset = 05 

OP-terminal 1 = 06 



When receiving a T-command with text part, MCD stores emergency 
text as the dynamic text part of a possible, future SOS packet. 
When receiving the T-command request, the stored emergency text 
is sent to the terminal, by the . T-command with text part. 

Description of the emergency packets and procedures (SOS, 
SOSINFO etc) can be found in "Network layer for terminals", see 
reference Rl-09. 
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2.9 O-command (send emergency signal SOS) 



The O-command is used by the terminal to initiate the 
transmission of an emergency signal (SOS packet). 

When receiving the O-command, MOT creates a SOS packet and sends 
it to the network. The text part of SOS is made up by the stored 
emergency text (received earlier by the T-command) where the 
identity of the emergency source is inserted as the first two 
octets. 

Description of the emergency packets and procedures (SOS, 
SOSINPO etc) can be. found in "Network layer for terminals", see 
reference Rl-09. 

When MOT is in manual mode, it is recommended that the MOT' • 
return to MOBITEX" operating-mode and sends tha packet MPAK:SOS. 
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(MAN request) 



The FP-coramand is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 

2.11 F Q-command (device handling the MASC protocol) 

The FQ-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 

2.12 F F-command (MCO in contacc with mobitex) 

The FF-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 



(MCU not in contact with mobitex) 
The FG-command is described in chapter TERMINAL SYSTEM FUNCTIONS 



2.14 F B-command- (MPAK sent .over-radio path) 

The FH-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command. 

2.15 F K-command (error message from MCU) 

The FK-comraand is described in chapter TERMINAL SYSTEM FUNCTIONS 



2.16 F o-command (prepare to close down) 

The FO-coramand is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-comraand . 

2.17 F f-command (short number list) 

The F#-command is described in chapter TERMINAL SYSTEM FUNCTIONS 
F-command . 
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3 TYPE TEST FUNCTIONS (always to be implemented in MCU) 

These functions should only be used during type testing and must 
be made inoperative for normal use. 



3.1 P-command (request/list of parameters) 

Structure of text field in request for internal parameters from 
terminal to MCU: 



m 

1 

Structure of text field in reply from MCU to terminal (list of 
parameters ) : 



- |- P I SP |-liSt--of -parameters] 



The data field is empty. 

The F-comraand is used by the terminal to request radio protocol 
parameters and by MCU to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). The parameters to be sent in the 
following order: 



Parameter 

Slot_length 
Timeout_short 
Timeout_long 
Free_slots 
Rand_slots 
Current_base 
Chosen_slot 
Max_access 
Max_rep 

Priority (internal parameter in MCU) 

Sequential number up (term. MAN) 

Sequential numbers down (term.MAN+15 groups) 

Upfreq (current) 

□ofreq (current) 

Flexlist (MAN 1-7) 

Grouplist (MAN 1-15) 



No of bytes 



(internal parameters in MCU) 
(internal parameters in MCU) 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 



A. 393 SUM 
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3.2 PA-command (request/list of radio-parameters) 

Structure of text field in request for internal Darameters £r< 
terminal to MCU: 



Structure of text field in reply from MCU to terminal (list of 
parameters) : 



1 p A01 | SP j^list of_paramaters] 

4 1 >=23 
The data field is empty. 

The PA-command is used by the terminal to- request .radio protocol 
parameters and by MCU to send these parameters as a reply to the 
request. . 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following orders 

Parameter 



Timeout 
Slot length 
Free~slots 
Rand~slots 
Max_rep 
Max~access 
Max~speech 
Txpow 
Slevl 
Slev2 
Scan time 
BadJEase 
Goodjbase 
Choose_base 
Better_base 
Qpos 

Current_base , pommctci. ±u t4 v« > 

Chosen_slot . (internal parameter in MCU) 
Priority (internal parameter in MCU, current value) 
Upfreq (current value) 
Dofreq (current value) 
•Access_channel_upfreq (current value) 
Access~channel dofreq (current value) 
Network id (mobile tx) 
Network~id (mobile rx) 
Area id 



No of bytes 



(internal parameter in MCU) 
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Example of PAOl-comniand: 
MOT 



PA01 01,02,03,04,05.06,07,08,09,10,11,12,13,14,15,16,0017, 
18,19,0020,0021,0022,0023,0024,0025,26 



PA01 01,02,03.04,,,, 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Hl-16. 
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(request/list of identity-parameters) 

Structure of text field in request for identity parameters from 
terminal to MOT: 



Structure of text field in reply from MCO to terminal (list of 
parameters ) : 



| SP I list of parameters! 



The data field is empty. 

The -p-command-is- used by the terminal to request radio protocol 
parameters and by MCU to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Parameter No of bvtes 

Terminal MAN 3 

ESN 4 

Flexlist (MAN 0-7) 21 

Grouplist (MAN 1-15) 45 

Sequential number up (term. MAN) i 

Sequential numbers down (term.MAN+15 groups) 16 

Example of PA02-command: 

MCU TERMINAL 



PA01 000001,00000002,000003,000004,000005, , , , ,000010, , , „ 
r, ,,,,,, ,,26,27,, ,,,,,,,,,,,,, 42 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3.4 BA-command (request/list of channel-parameters) 

Structure of text field in request for parameters from terminal 
to MCO: 



Structure of text field in reply from MCtl to terminal (list of 
parameters): 



1 j^list of parameters^] 



4 1 >=4 

The data field is empty. 

The P-command -is -used by -the terminal . to -request radio protocol 
parameters and by MCO to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Parameter Ho of bytes 

Channel_list (current) 1 
Number_of_channels in channel_list (total) 

Number of_channels in this < J 

Channel #1 - upfreq 
Channel #1 - dofreq 
Channel #2 - upfreq 
Channel #2 - dofreq 



Channel-list = Ol(hex) DEFAULT LIST 

02 (hex) " CURRENT LIST 
03(hex) TEMP_DEPAULT_L 1ST 

All parameters in this command is a number of ASCII coded hex 
number . 

Example: Answer with a default list of 100 channels. 

PA03 01, 0064, 3C,0123, 0123, 

PA03 01,0064,28,0123,0123,....,.. 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3 - 5 PA-command (reguest/list of roaming-parameters 1 
to r ilco- re ° f t6Xt fi6ld in request for Parameters from terminal 

1 PA05 | 

4 " 

pirS2t«a)- t6Xt field ln rSply £r ° m MCD " cecminal < lis - ^ 



p&05 I SP Jj-ist of parameter!] 



The data field is empty. 
-■-■^-P-ooBaaaa-is-used by the terminal to request radio -protocol - 
?eq^2st erS y MCtI tD Sfind thSSe P aramet «s as a reply to the 

^ e K list ° f P ara ? eter s consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: co 

Parameter No of bvtes 

Number of bases in table i 

Current base id 2 

roaming~value f 

Base_id - £ 

roaming_value 1 



Example: Mobile terminal with current_base(23) choosen. 

PA05 03,0023,09,0025,02,0019,04 

Mobile terminal with no choosen current_base. 

PA05 03,,, 0023,02, 0019, 01 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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PA-command (request/list of test-parameters) 



PA06 SP function 



in; 



Structure of text field in reply from MCU to terminal (list of 
parameters): 



| PA06 | SP | function j , | list of_parameters] 

4 1 2 1 >=1 

The data field is empty. 

The. P-command is used by.. the- terminal to request;.. foe. radio, 
protocol parameters and* by MCD to send these parameters as a 
reply to the request. 

The function is a ASCII coded decimal number between 00'- 99, 
describing separate request or answer. Those functions are 
described below. 

The list of .parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Function: 

tto£ description: parameter: 

01 current_base(Req/ans) In the answer, the current_base 

is in ASCII coded hex number. 

02 set current_base . Current_base in ASCII coded hex 

number . 

03 disable base searchjnode - 

04 enable base_iearch_raode 

05 clear dynamic memory 

06 enable copy REPMAP when 
receiving or sending the 

frame <REB> An ASCII coded hex number for 

each bit set to "1" indicating 
repetition in the frame <REB>. A 
comma is placed between each 
number. 

07 disable copy REPMAP 

08 enable loudspeaker 

09 disable loudspeaker 
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description; parameter: 

The parameter 'nomret in ASCII 
coded hex number, stating the 
number af retransmissions, 
enable transmitting the 
scrambling signal over 
the radio (see ref Hl-17 ) - 
disable transmitting the 
scrambling signal over 
•the radio(see ref Rl-17 ) - 

copy speech parameters. Subscriber, con-id, upfreq, 
dofreq. Parameters in" ASCII 
coded hex number separated by a 



Example: HOT Terminal 

< PA6 01 

PA6 01 ,1234— — > 

<— ' PA6 02,1234 



PA6 06,6,23,35 



PA6 06 



PA6 13,123456,12,1111,2222 





PA6 


07 




PA6 
PA6 


08 
09 




PA6 


10 




PA6 
PA6 


12 

11 




PA6 


13 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3 « 7 K-command (receive/transmit frequency number) 
Structure of text field to frequency number reception! 



KM | SP I parameter 



Structure of text field to frequency number, transmission: 



The data field is empty in both commands. 

The parameter field-states -the frequency number. The number is 
given as the ASCII codes of the hexadecimal digits of the 
frequency number in hexadecimal notation. 

The K-comraand is used to set up the frequency pair to be used 
for reception and transmission. The frequency number range is 
hexadecimal 001 - 617 (decimal 0001 - 1559). 

If the frequency number included in the frame is not implemented 
in the equipment, MOT will respond with an E-frame (error 
function). 

For correspondence between frequency number and frequency, see 
reference Rl-06 . 



Exhibit 2, p. 



777 



Cantel Mobitex- 



2/105S - A 296 5175/2 Ue 



1990-02-26 A 



3.8 KA-command (receive/transmit frequency number) 
Structure of text field to frequency band: 



Structure of text field to frequency number . reception: 



SP | parameter 



Structure of text field to frequency number transmission: 



KAS I SP I parameter 



The data field is empty in all commands. 

The parameter FBI states the frequency band and bitrate. The 
parameter is given as the ASCII coded hex number of the 
parameter FBI in upfreq and dofreq. 

The parameter field states the frequency number. The number is 
given as the ASCII codes, of the hexadecimal digits of the 
frequency number in hexadecimal notation. 

The KA-rcommand is used to set up the frequency pair to be used 
for reception and transmission. The frequency number range is 
hexadecimal 0001 - 1FFF (decimal 0001 - 8191). 

If the frequency number included in the frame is not implemented 
in the equipment, MCU will respond with an E-frame (error 
function) . 

For correspondence between frequency number and frequency, and 
frequency band(FBI) and bitrate , see reference Rl-06. 
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4 TERMINAL SYSTEM FUNCTIONS (implemented according to 
application) 

4.0 F-command (system control) 

The F-command is used from on. terminal to execute the soecified 
function in MOT. 

The F-command is used by MOT to send information to the 
terminal. 

Structure of the text field: 



list of parameters 



The data field is used only in the FT- and F#-frame with list of 
channel numbers and short numbers. 

..The list, of parameters is a . list of one-character function codes 
and parameters in ASCII code according to the following table: 

4.1 F B Change to MOBITEX operation mode 

MOT sends an ACTIVE packet to the network 

4.2 F C Set up a MOBITEX line connection 

parameters MAN1,MAN2 

MAN is a 6-digit ASCII-coded hex-number. 

MANl=sender, MAN2=addressee. 

MOT creates and sends a CONREQ packet to the 

network. 

4.3 F D Set up a TELEPHONE line connection 

Parameters MAN, TEL 

MAN is a 6-digit ASCII-coded hex-number (sender). 
TEL is the desired number in the telephone network. 
The number is given in MOBITEX textcode, right 
justified in a 20 character field with leading 
spaces according to the corresponding field of 
EXTCONREQ. 

MOT creates and sends an EXTCONREQ packet to the 
network. 

4.4 F E Disconnect line connection 

MOT creates and sends a DISCON packet to the 
network. 

4.5 F F Contact with the MOBITEX network 

"MCO is in contact with the MOBITEX network. 

4.6 ' F G No contact with MOBITEX network 

MCO has no contact with the MOBITEX network and is 
trying to establish contact again (roaming procedure 
started). 
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MPAK sent by the radio to the network 
Parameter SEQU-ID 

MCU inform that MPAK has been sent to the network. 
The parameter SEQU-ID is added if SEQU-ID was 
included in the M-comtnand. SEQO-ID is a 1-digit 
ASCII coded decimal number between 0-9. 

Cancell previously transmission of MPAK 
Previously activated transmission of MPAK is 
cancelled. The MPAK =o be returned za the terminal 
by an N-frame. 

Print out current MANs in terminal 

Print current MANs in terminal on printer (terminal 

subscription MAN, group MANs (group list) and 

personal subscription MANs (flex list) in that 

order. 

Error message about a fault situation 
Parameter XX 

- Error message where XX is the error -number in-ASCII 
coded hex digits 00-FF (0-255). . 
Information from MCU about a fault situation. 
Description of the meaning fault situation see 
chapter "Fault situation in mobitex mobile 
stations". 

Activate external call indication 

Activate external indication (e.g. horn) for 2 

seconds . 

Transmitter on/off 
Parameter X 

X = character 0 > transmitter off 

X ■ character 1 > transmitter on 

Change to MANUAL RADIO mode 

MCU sends an INACTIVE packet to the network. 

Prepare for closing down MCD 

From terminal: Command to prepare closing down 

(switching off) the MCD . 

MCU clears buffers for stored MPAKs. MPAKs to be 
transmitted to the network are transmitted. All 
other MPAKs are sent to the terminal. If no contact 
with the network, MPAK's to the network are returned 
by the N-command. 

Then MCU sends an INACTIVE packet to the network. 
Finally MCU confirms that it is empty by sending a 
' FO-frame to the terminal. 
From MCU: MCU is empty and ready to be switched off. 

Note: If more than one device connected, the FO- 
command from the MCU should be sent to all 
devices. 
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4.15 F P Terminal MAN request/answer 

Request from terminal for terminal subscription MAN. 

F PXXXXXX Terminal subscription MAN from MCU to 
terminal as response to the request. 
XXXXXX is the MAN as a 6 digit ASCII coded 
hex number. 

4.16' F Q MASC device identity 
Parameter XXX 

Type of device handling the MASC protocol. 
F_Q(MASC_DEVICE) is information to other units 
connected to this MASC interface. 
XXX = MCO 
XXX = MOX 

4.17 F R Change network identification 

Parameters XXXX.YYYY 

Send this new network identification to data link 
layer(see reference Rl-16). 
- - JCXXX = is new network_ID for mobile tx in ASCII 

coded hex number. 
YYYY = is new network_ID for mobile rx in ASCII 

coded hex number. 

4.18 F S Change AREA-LIST 

Parameters BITMAP.COM 

Send this new area list to data link layer (see 

reference Rl-09 and Rl-16). 

BITMAP = see AREALIST reference Rl-09. 

COM = see Command reference Rl-09. 

Parameters BITMAP and COM is in ASCII coded hex 

digits. 



Change TEMP_DEFAULT_L I ST 
Parameters TNDM,N0M,M 

Send this new channel list to data link layer (see 
reference Rl-09 and Rl-16). 

TNUM = Total number of channels. If TNUM is zero, 
delete TEMP_DEFADLT LIST and return to 
DEFA0I.T_I.IST. ~ 

NUM = Number of channels in this command 

M = 0 No more channels 

M =1 More channels in next command. 

Parameters TNUM, NUM and M is in ASCII coded hex 

digits. 

The list itself is sent in the data field of the 
frame. The list is described in reference Rl-16. 
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4.20 P 7 Speech queue information 

Parameter XX 

Information about queue-position when waiting for 
speech to be connected. 

XX is the speech-queue number in ASCII coded hex 
digits in the range 00-FF. 

4.21 F # Short number lisc 

Request from terminal for short number list. 

F SXX List of short numbers from MCU or terminal. 

The list contains short, numbers which'are 
common to MCU and all connected terminals 
(general short numbers). It is sent by the 
terminal to set up this list and by MCU as a 
reply to the P# request frame from the 
terminal. 

XX is the number of short numbers in the 
list in ASCII coded hex digits in the range 
00-32 (0-50 decimal). 

The list itself -is sent in -the data field -of- - 

the frame. In the list, the actual numbers 
corresponding to each short number from 1 
and up are given as ASCII coded digits with 
a maximum of 20 digits each - . The numbers are 
separated by the character , (comma). 

NOTE: Only the 'one-character function* can be included in an F- 
command, e.g. p P123456. 

Description of the different packets and procedures mentioned 
here can be found in reference Rl-09 and Rl-16. 
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5 AUDIO FUNCTIONS (implemented according to .application) 
5 . 0 A-command (controlling audio functions) - 
Structure of text field: 



I A | SP I list of parameters | 
1 1 >=1 — 

The data field is empty. 

The A-command is used to control the audio equipment. 

The list of parameters is a list of one-character function codes 
and parameters in ASCII code according to the following table: 

5.1 A B Increase audio volume level 

5.2 AC Decrease- audio, volume, level 

5.3 .AD Loudspeaker on/off 

Parameter X 

X « character 0 — > off 
X = character 1 — > on 

5.4 A E External call indication on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.5 AH Microphone (hook) on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.6 A I Transmit/receive switch 

Parameter X 

X = character 0 — > transmit 
X » character 1 — > receive 

5.7 A J Hands free. 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.8 A V Audio level order. 

Parameter X 

X=data, ASCII coded hex digit 0-F. 

NOTE: Only the "one-character function' can be included in an A- 
command, e.g. A EO. 
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6 MANUAL RADIO MODE FUNCTIONS (implemented according to 
application) 

6.0 H-conunand (controlling manual radio mode) 

Structure of text field: 



j H I SP I list of parameters [ 
1 1 >=1 
The data field is empty. 

The H-command is used to control the radio equipment when in 
manual radio mode. 

The list of parameters field is a list of one-character function 
codes and parameters in ASCII code according to the following 
table: 

6.1 HA Change to MOB I TEX mode. 

MCU sends an ACTIVE packet to the network. 

6.2 H B Increase audio volume level. 

6.3 EC Decrease audio volume level. 

6.4 H D Loudspeaker on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.5 HE External call indication on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.6 H F Call indication 

Parameter X 

X = character 0 — > no call received 
X = character 1 — > call received 

6.7 E G Squelch open/closed (toggle). 

6.8 EH Microphone (hook) on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.9 HI Transmit/receive switch 

Parameter X 

X = character 0 — > transmit 
X = character 1 — > receive 
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Hands free. 
Parameter X 

X = character 0 — > transmit 
X = character. 1 — > receive 

Change co channel number. 
Parameter XX 

Change zo channel number XX where XX is the desired 
channel number in ASCII coded hex digits in the 
range 01-63 (1-99 decimal). 

Channel number indication. 
Parameter XX 

XX is the channel number in ASCII coded hex digits 
in the range 01-63 (1-99 decimal). Will be sent, whem 
start up or a changed channel occur. 

Send selective, call number. 
Parameter XXXXXXX 

Send selective call number XXXXXXX on current 
...channel. 

X is an ASCII coded digit 0-9. 

If the number of digits is less than 7, the number 
will be left justified and the XXXXXXX-f ield will be 
filled with trailing spaces (hex code 20). 

Scan the specified channels. 
Parameter XX.. XX 

XX.. XX is a list of maximum 8 channel numbers in a 
field of 16 octets. Each XX represents a channel 
number in ASCII coded hex digits in the range 01-63 
(1-99 decimal). If the number of channels is less 
than 8, the field will be filled with trailing 
spaces (hex code 20). 

The specified channels are scanned for' carrier or 
selective call. 

Carrier indication. 
Parameter X 

The frame must be transmitted only when there is a 

change between sensing carrier and sensing no 

carrier. The carrier sense itself should be "updated 

at least once per second. 

X = character 0 — > no carrier 

X = character 1 — > carrier 

Copy of own selective number. 
Parameter XXXXXXX 

Copy of the own selective call number. 
X is an ASCII coded digit 0-9. 

If the number of digits is less than 7, the number 
will be left justified and the XXXXXXX- field will be 
filled with trailing spaces (hex code 20). ' 

Transmit/receive indicator 
Parameter X 
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— > transmitting (sending) 
— > receiving (monitoring) 



Note: Only the 'one-character function' can be included in an 1 
command, e.g. H P1234S67- 
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7 Signalling between HCU and terminal equipment connected to 
the MASC interface. '. 

7 . 0 General 

. These chapters have been included because she network layer may 
be differently implemented in different terminal equipment. For 
any terminal equipment, connected to MCO via the MASC* interface, 
the MCO can be considered as a DCE for connection to the MOB I TEX 
network. A terminal can have a complete MOBITEX network layer or 
a simplified network layer, using different commands of the MASC 
protocol. 

A terminal connected to the MCO must have the same terminal MAN 
number as the MCU. 

The terminal MAN must be associated to at least one output 
connection, either a MASC interface or another connection (e.g. 
a handset or a printer). 

All messages to groups, belonging to terminal MAN, should be' 
directed to the same output connection(s) as terminal MAN. 

The MCU has the responsibility towards the MOBITEX network 
according to the network . layer . 

In order to get the MOBITEX network layer in MCO and the 
terminal to interact correctly, the following chapters have to 
be considered. 



7.1 MPAK received from the network 

ROAMORD , FLEXREQ , INFOREQ and ESNREQ will be completely handled 
within the MCO without notifying any connected terminal. 

DIE and LIVE will be completely handled within the MCU but 
notified by FK-comraand(if handled) to connected terminals. 

All other correctly received MPAKs will, after normal handling 
in the MCO, be sent to the output connection where the addressed 
MAN is located. 

A fixed terminal can't receive a CONORD, therefore CONORD is to 
be converted to a CONREQ by the MCO. 
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7.2 MPAK received from a terminal 

Normally, if the MPAK passes the checks in the MCU, the MPAK 
will be sent to the network. The MCU should react and enter 
states as if the MPAK was generaced in che MCU (e.g. on CONREQ 
the MCU should enter a scace for call in progress, and should 
axso act according to the radio protocol for sending such MPAK) . 

If the checks fail, the MPAK should he returned to the rermina- 
by an R-frame. 

For the following MPAK's, however, the MCU should have a sDecial 
treatment. 

CONREA to be treated as a hook off -signal 

DISCON .. to be treated as a hook on-signal 



FLEXREQ 



if the personal subscription already 
exist "±n-flexlist the terminal will be 
informed by FK-frame. 



FLEXLIST 



to be returned to the terminal by an R- 
frame. 



BORN, 
ROAM, 
INFO, 



ESNINFO 



to be returned to the terminal by an R~ 



f rame. 



LI NEON, 
LINEOFF 



to be returned to the terminal by an R- 



frame. 



A2S2 51M/3 



Exhibit 2, p. 788 



Cantel Mobitex- 



2/1056 - A 296 5175/2 Ue 



7.3 Connection between the MCO and the terminal 

The terminal is supposed to have a list of groupMAN's and a list 
of personal subscriotions (fiexlist). In order to get the lists 
in the MCO equivalent to the list in the terminal, the following 
should be considered. 

Each time the link layer connection is established (by exchange 
of B-frames), the terminal will send: 

- MANREQ (command F ?) to request MCO for the terminal MAN 

To answer this, the MCO sends the terminal MAN in the command 
MAN (command F P). This answer should be sent immediately or, if 
another frame is currently being transmitted by the MCO, 
immediately after the transmission is completed. After that, 
the MCO will send the MASC_DEVICE command (F Q). 

The MCO should send: 

__. - GROOPLIST— ■ . to- set the list of groupMAN in. the 
terminal 

- FLEXLIST to set the fiexlist in the terminal. 

The terminal will then handle the fiexlist according to the 
specification, see Rl-09. 
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Example of start sequence when MCU starts. 




MCU 


TERMINAL 




B-frame — > 

MAN-frame > 

MASC DEVICE- frame > 


MANREQ- frame 




GROUPLIST > 






Example of start sequence when TERMINAL starts: 




MCU 


TERMINAL 




MAN-frame ' > 

MASC DEVICE-f rame > 


-S- frame 
MANREQ- frame 




GROUPLIST > 

• FLEXLIST > 






Note: Packets above the dotted line in each sequence 
belong to the link layer, and packets below the 
dotted line belong to the network layer. 




7.4 Signalling between MCU and more than one terminal 




The MCU may have more than one MASC interface. 




All MASC interfaces should have the same start sequence as 
described in chapter "Connection between the MCU and the 
terminal" . 




The MCU handles all MPAKs and messages to different output 
connections where the MAN is located. 
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7.5 Description of a system with MASC interface. 
7.5.1 MCO connected to one terminal. 



MCU handles the terminal MAN, group MAN and' personal MAN with 
GROOPLIST and FLEXLIST in the start sequence. 

After the start sequence, all MPAKs are routed to the terminal. 
7.5.2 MCU connected to two terminals. 













MASC2 . 


TERMINAL2 




MCO 






MASC1 




MASC3 1 




TERMINALl 


—jUNITl 






MASC 4 | 








= — (UNIT2 



MCD handles the terminal MAN, group MAN and personal MAN with 
GROOPLIST and FLEXLIST in the start sequence. 

All terminals that have other terminal equipment connected, will 
have the same start sequence as described in chapter "Connection 
between the MCO and the terminal". These terminals should be 
considered as an MCO by the connected units. 

After the start up sequence ali MPAKs are routed to the current 
terminal . 
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Examples of start sequences. 




EXAMPLE 1. 




Lists, when MAN are correct and MCU starts. 


TERMINAL2 MCU 


TEHMINALl UNITI CSIT2 


S-frame > 





MASC_DEVICE — — 
< B-frame 
MANREQ — > 

< MAN 

< MASC_DEVICE-frame 



< ~GROCJPLIST 

GROUPLIST > 

< FLEXLIST 

FLEXLIST > 

GROUPLIST > 

GROUPLIST 

FLEXLIST > 

FLEXLIST ~ 



Note; Packets above the dotted line in the sequence belong 

to the link layer, and packets below the dotted line 
belong to the network layer. 



a aw sum 
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MAN1 is only in ONIT1 and TERMINALl. MAN2 is only in' MCU. 
MAN1 and MAN2 are personal siibsciptions not included in MCO': 
flexlist. 

TERMINAL2 MCU TERMINALl UNIT1 UNIT 2 

B- frame > 

< MANREQ 

MAN > 

MASC_DEVICE > 

< B- frame 



■ GROCPLIST 
GROOPLIST 

■ FLEXLIST 
FLEXLIST 



Note 2: 
Note 3: 



The terminal/unitl/unit2 will replace former lists with 
these new lists. When replacing the flexlist the 
terminal/unitl/unit2 will decide if MAN1 and MAN2 are 
connected or disconnected. If connected, a loginreq is 
sent from MAN1 in unitl and a loginreq sent from MAN2 
in unit2. If not connected an presentation of the 
logout is sent to the user. 

The application in ONIT1 has to send LOGINREQ for MAN1 
if it wishes to keep MAN1. 

Packets above the dotted line in the sequence belong to 
■the link layer, and packets below the dotted line 
belong to the network layer. 



MCO 



TERMINALl 



DNIT1 0NIT2 



-LOGINREQ 
for MANI 




AS9ZSIS3/J 
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EXAMPLE 3. 

TEHMINAL1 is starting the. connection. 

TERMINALS MCO TERM! MALI DNIT1 0NIT2 

< B-frame 

< MANREQ 

MAN > 

MASC_DEVICE > . 

B-frame > 

< MANREQ 

MAN > 

MASC_DEVICE— > 

B-frame > 

< i MANREQ 



MASC_DEVICE- 



" GROUPLIST 
GROOPLIST 

• FLEXLIST 
FLEXLIST 



Packets above the dotted line in the sequence belong to 
the link layer, and packets below the dotted line belong 
to the network layer. 



A.SS2J1SM 
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7.5 Fault 


situation in mobitex mobile stations. 


This is a recommendation of error message from* the MCU to the 
connected unit using a MASC interface. This error message is a 
response for a fault situation and sent as an error number in 
. the FK-command(see chapter "Information frame commands and 
functions"). 


Error numbers 0 - 4F is reserved for specific meaning. Error 
numbers 50 - FF is free to use. 


New meaning 


of error numbers is 


described in Rl-06. 


Error no: 


meaning: 




0 


reserved 




1 


DIE mode. 


An MPAK-.DIE is received. No user 
traffic can be sent from the 


2 


LIVE mode. 


An MPAK:L.IVE is received. . Dser 
traffic can be sent from the 
MCU. 


3 


SPEECH mode. 


The MCU is in speech mode and 
can not send any traffic except 
MPAK:CSUBCOM. 


4 


MANUAL mode. 


The MCU is in the manual mode 
and not in contact with mobitex 
network. . 


5 


reserved 




•6 


reserved 




7 


reserved 




8 


reserved 




9 


reserved 




A 


Receiver buffer full, waiting for free buffer. 


B 


Buffer/memory free. 




C 


No memory, waiting for more memory. 


D 


reserved 




E 


reserved 




F 


reserved 
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Error no; 


meaning. 




Returned MPAK during die mode. 




Returned MPAK during speech mode. 




Returned MPAK during manual mode. 




Returned MPAK during buffer full. 




reserved 




reserved 




Loginrequest MAN already exist in 


17 


Loginrequest MAN is not possible, 


* 8 


MPAK sender MAN is not in TMAN or 


19 


reserved 


1A 


reserved 


IB 


reserved 


1C 


reserved 


ID 


reserved 


IE 


reserved 


IF 


reserved 


20 - 4F 


reserved 
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8 HOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 27, 28, 45 

Hl-09, 9, 11, 12, 14, 15, 16, 17, 31, 32, 39 
Rl-16, 19, 21, 22, 23, 24, 26, 31, 32 
Rl-17, 26 



Below are the reference designations listed. 
Reference - Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 
Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
-44QBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 
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APPLICATION EXAMPLE 
OF HOW TO MAKE AN ALTERNATE CONNECTION VIA MCU 
FOR FIXED TERMINALS WITH MASC INTERFACE. 
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1 INTRODUCTION 

This document describes an example (i.e. not a 
specification) of an- MCO application. Its Durpose is to 
aake it easier for zhe manufacturers. ?or Vne 
understanding of chis documanc, zhe reader has to be well 
informed about the Networx layer for terminals { reference 
Rl-09 ) and Link layer for mobile terminals { reference 



A fixed terminal may be directly connected to the MOBITEX 
network via a masc interface (MASC) see document "Other 
interfaces" and appendix A "Commands". The aoplication in 
this document describes how sucn a terminal may be 
connected via an MCtI, that handles the masc interface. As 
to the requirements of such a terminal, Dlease refer to 
chapter 7 in this document. 
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2 MCO WITH APPLICATION 

Figure 1 shows an MCU with its processes. Each orocess 
communicates with the other processes as is indicated by 
the arrows in the figure. 



AUDIO HANDLER 

"AUDIO" 



APPLICATION 
DIRECTOR 

"APP DIR" 



MASC HANDLER 1 
"MASC1" 



MASC HANDLER ! 

"MASCn" 



NETWORK LAYER 
"RADIO NET" 



In the centre of figure 1 is a process called APP_DIR, 
application director. This document will describe that 
process. 



The audio handler (AODIO) handles an audio interface. 

The printer handler (PRINTER) handles a printer, connected 
to the MCU. 

Furthermore one may have "emergency handler", "terminal 
with small display handler" etc. 

The network layer (RADIO_NET) is a normal MOB I TEX network 
layer for mobile terminal, plus the additions made in 
chapter 7 (Requirements on network layer in MCU in this 
application). 
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The letters A, B and C represent different signalling 
sequencies. Observe that the HASC handler and the r>r inter 
handler acts similarly towards the application director. 
All handlers act in the same way as an MASC handler 
towards the application director. 



Following terms are used in this document: 

- line handler common name for all handlers. E.g. 

HASC1 , MASC7 , AUDIO ... 

- MCO_MAN the mobile terminal's MOBITEX 

subscription number. 
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3 DESCRIPTION OF SIGNALS 

All signals that are handled by APPJJIR have che following 
structure: 



origin 



signal_status 



Original sender. Can be: line handler, 
RADIOJJET or 
APP DIR. 



Sender. Can be : 



line handler, 
RADIOJIET or 
APP .DIR. 



Signal status can be signal_status_olc or 
signal_status_not sent. 
Signal status is always set to 
signal_status_ok when the signal is 
created. 

If the RADIO_NET or any of the line 
' handlers fails to transmit a signal, 
signal status will be set to 
signal_status-_not_sent. Then the signal 
is returned to APP_DIR. 

Can be: S hook on, 
S_hook~off , 
S_MPAK, 

S~MPAK_sent_on_radio , 
S_returned_incor rect_MPAK , 
S_not_sent_MPAK 
S_line_up,~ 
S_line_down. 

If signal_type isS_MPAK, S_not_sent_MPAK 
or S_returned incorrect_MPAK, it contains 
an HPAK in this field. 



A ±U 515313 
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Description of the signal types; 
. S line up 

S_line_up is sent fay all line handlers to APP_DIR after a 
correct start or restart. 

If the line handler is an MASC_handler , the starting up 
■ sequence will send a PRIM_MASC~f rame and an 
acknowledgement of this will be received from the 
connected unit before S_line_up may be sent. 

If the line handler is a PRINTER , it is recommended that 
S_line_up is not sent until the modem signals say there is 
a printer connected. 



S line down 

S line down is sent by all line handlers to APP_DIR when 
tEe unit is disconnected. 

"if the line handier fails to transmit a signal to the 
connected unit, S_line_down will be sent to APP_DIR 
together with the~signal being returned. ~ 



S_HPAK is the normal signal being sent between line 
handler and AFP_DIR and between RADIO_NET and APP_DIR. In 
the normal case, signal status is signal_status_ok. But in 
the case when line handler or RADIOJJET fails to transmit 
the signal, signal status will be set to 

signal_status not_sent and the signal will be returned to 
APP_DIR, For Further information see examples below 
{chapter 4) . 

When an S MPAK is received by the MASC-handler, the MASC- 
handler must send an M-frame to the connected unit 
according to the raasc protocol. 

When an M-frame is transmitted from the connected unit , to 
the MASC-handler, the MASC-handler must send an S_MPAK to 
APP DIR. 



S returned incorrect MPAK. 

S_returned_incorrect_MPAK is sent by APP DIR to line 
handler if an incorrect MPAK was received".. . 

If an-MASC handler receives a s_returned_incorrect_MPAK, . 
this MPAK will be sent to the connected unit in an R-frame 
according to the masc protocol. 
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S not sent MPAK. 

S_not_sent_MPAK is sent by APP DIR to line handler if, for 
some reason, it is impossible to transmict a mnaic on 
radio. 

If an MASC handler receives a S not sent MPAK, this MPAK 
will be sent to the connected unit in an N-frame accordinq 
to the masc protocol. 

S MPAK sent on radio 

s_MPAK_sent_on_radio is sent by RADIO NET to APP oir when 
an MPAK has been sent via radio. Origin helps APP dir - 0 
direct this signal to correct line-handler. When the MASC 
handler receives an S_MPAK_sent_on_radio, it uses the masc 
F _ H ~«ame to send the signal to connected unit. 

S hook off 

S_hook_off is sent by AUDIO to APP DIR at hook off. 
APP_DIR updates its registers and passes the signal on to 
RADIO_NE.T. 

An MPAK CONREA, received by APP DIR' from connected unit, 
will not be sent to RADIO_NET. Instead S hook off will be 
sent from APP_DIR to RADIO NET. ~ ~ 

S hook on 

S hook_on is sent by AUDIO to APP_DIR at hook on. APP DIR 
updates its registers and passes the signal on to 
RADI0_NET. 

An MPAK DISCON, received by APP_DIR from connected unit, 
will not be sent to RADIO NET. Instead S hook on will be 
sent from APP DIR to RADIO NET. 
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4 EXAMPLES OF SIGNALLING IN THIS APPLICATION 

4.1 EXAMPLE 1: sending TEXT successfully 

Unit A sends an MPAK TEXT to a subscriber 3 in the MOBITEX 
network. Transmission via radio is successful. 



TERMINAL A 



protocol 



signal signal_type 



origin 



from 



signal_status 



1 raasc frame M 

2 S_MPAK MASCn MASCn 

3 S_MPAK MASCn APP_DIR 
4-6 are not handled in this document. 

7 S_MPAK_sent_on_radio MASCn RADIO_NET signal_status_ok 



signal_status_ok 
signal_status_ok 



S_MPAK_sent_on_radio MASCn 
masc frame F H 



APP_dir signal_status_ok 



Observe that origin = MASCn through the whole sequence. 
This gives APP_DIR an opportunity to route signals easier 
back to the sender. 
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4.2 EXAMPLE 2: sending TEXT unsuccessfully 

Onit A sends an MPAK TEXT to a subscriber B in the MOB I TEX 
network. APPJ3IR discovers some kind of error. 



TERMINAL A 


MCU 








MASCn 


2 


APP DIR 




4 • 

MASC 
protocol 






3 


RADIO_NET 
ROSI 



signal signal_type origin from signal_status 

1 masc frame M 

2 S_MPAK MASCn MASCn signal_status ok 

3 S_returned- 

I _incorrect_MPAK MASCn APP_DIR signal_st:atus ok 

4 masc frame R 

Observe that signal 3 has signal status set to 
signal_status_ok. Only line handlers and RADtO_NET may set 
signal status to signal_status_not sent. 



A-.Q2SI513 
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4.3 EXAMPLE 3: sending TEXT unsuccessfully 

Onit A sends an MPAK TEXT to a subscriber 3 in the MOBITEX 
network. Transmission via radio fails. 



TERMINAL A 

■ 


MCU 


i 

> 

MASCn 

< 


APP DIR 


9 

HASC 
— ... protocol - 


1 a 


7 | |,. 


RADIO NET 




«l I 4 ■ 




ROSI " 



15 

FAIL . 



signal signal_type 



origin 



from 



signal_status 



signal_status_ok 
signal_status_ok 



1 raasc frame M 

2 S MPAK MASCn MASCn 

3 S MPAK MASCn APP_DIR 
4-6 are not handled in this document. 

7 S_MPAK MASCn RADI0_NET signal_status- 

~ not_sent 

8 S_not_sent_MPAK MASCn APP_DIR signal_status_ok 

9 masc frame N 
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4.4 EXAMPLE 4: sending TEXT unsuccessfully. 

Unit A sends an MPAK TEXT eo a subscriber B in the MOBITEX 
network. Transmission wia radio fails. The MCO fails =o 
return the packet co unit A. 



Q 



FAIL< — 
9 



HASC 
protocol 



FAIL 



signal signaltype origin from signal_status 

1 masc frame M 

2 S_MPAK MASCn MASCn signal status ok 

3 S_MPAK MASCn APP_DIR signal~status~ok 
4-6 are not handled in this document. 

7 S_MPAK MASCn RADIO JJET signal_statqs- 

not sent 

8 S_not_sent_MPAK MASCn APP_DIR signal status ok 

9 masc frame N ~ ~ ~~ 

10 S_not_sent_MPAK . MASCn MASCn signal_scatus- 

_not_sent 

This sequence is the same as the one in example 3, except 
for signal 10. When receiving signal 10, APPJ3IR discovers 
that origin = from, i.e. the signal is returned even from 
t.he MASC handler. The only thing APP DIP. can do is to 
forget the signal. 
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4.5 EXAMPLE 5: receiving TEXT successfully 
MCU receives an MPAK TEXT, addressed to MCU-MAN. 



Q 



MASC 
protocol 



signal signal_type origin from signal_status 

1-2 are not handled in this document. 

3 S_MPAK RADIOJJET RADIOJJET signal status ok 

4 S_HPAK RADIO_NET APP_DIR signal status_ok 

5 • masc frame M 



The sequence above is valid if there is only one line 
handler. 

If an MPAK is addressed to the MCU_MAN , and there is more 
than one line handler, APP DIR. will send a copy of signal 
4 to each one of them. But~if the MPAK is addressed to a 
transferred MAN, APP_DIR will know on which of the line 
handlers this MAN can be reached. 
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4.6 . EXAMPLE 6: receiving TEXT unsuccessfully 

MCD receives an MPAK TEXT to unit 3. Transmission to unit 
B fails. There is only one recevier in this example and 
MPAK is addressed to MCO MAN. 



MASC 
protocol 



signal signal_type 



origin 



signal_status 



■ 2 are not handled in this document. 



S_MPAK 
S_MPAK 
masc frame M 
S MPAK 



RADIO_NET RADI0_NET signai_status_ok 
RADIO_NET APP_DIR signal_status_ok 



RADIO NET MASCn 



Observe that an MPAK, addressed to MCU_MAN or any MAN 
included in the grouplist, must not under any 
circumstances, be returned to the MOBITEX network. In this 
application, APP DIR forgets the MPAK. 



Exhibit 



2, p. 811 



15 



Cantel Mobitex~ 



1/1056 - A 296 5175 Oe 



1990-02-23 3 j" MTS19B.1 



4.7 EXAMPLE 7: receiving CONREQ 

MCD receives an MPAK CONREQ addressed to unit B. Unit 3 
responds with an MPAK CONREA after which the call can 
begin. Dnit B terminates the call by sending an MPAK 
DISCON. 



|3 |b T 



2 9 1 14 



signal signal_type 



origin from signal_status 



RADIO NET signal status_ok 
app_dir signaljstatus_ok 



signal_status ok 
signal_status~ok 



1-2 are not handled in this document 

3 S_MPAK RADIO_NEX 

4 S_MPAK RADIO_NET 

5 raasc frame M 

6 masc frame M 

7 SJ4PAK HASCn HASCn 

8 SJiook off MASCn APP_DIR 
9-10 are not handled in this document. 

11 masc frame H 

12 S_MPAK HASCn MASCn 

13 S_hook_on MASCn APP_DIR 

14 - 15 are not handled in this document 

Note: signal 1-5 contains MPAK CONREQ. 

signal 6-7, 9-10 contains MPAK CONREA 
signal 11-12, 14-15 contains MPAK DISCON 

. In this application S_hook_on and S_hook_off are always 
sent, instead of MPAK DISCON and MPAK CONREA, to the 
RADIO NET. 



signal_status_ok 
signal_status_ok 
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4.8 EXAMPLE 8: receiving CONREQ 

MCO receives an MPAK CONREQ addressed to unit B. The audio 
interface generates a hook off after which the call can 
begin. The call is" terminated by the audio interface 
generating an hook on. 



protocol 



3 17 111. 



2 8 12 



signal signal_type 



origin 



signal_status 



RADIO_NET signal_status_ok 
APP_DIR signal_status_ok 



AUDIO 
APP DIR 



• 2 are not handled in this document 
S_MPAK RADIOJJET 
S_MPAK RADIOJJET 

masc frame M 

S hook off AUDIO 
S~hook~off AUDIO 

9 are not~handled in this document. 



S_hook_on AUDIO AUDIO 

S_hook_on AUDIO APP_DIR 

• 13 are not handled in this document 

S MPAK RADIO_NET APP_DIR 

masc frame M 

: signal 1-5 contains MPAK CONREQ 
signal 8-9 contains MPAK CONREA 
signal 12 - 15 contains MPAK DISCON 



Observe that APP_DIR generates MPAK DISCON to unit B 
This is to avoid blocking situations in unit B. 



signal_status_ok 
signal_status_ok 



signal_status_ok 
signai_status~ok 



signal_status_ok 
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5 LISTS OF SIGNALS 




Signals that are sent within the MCU, interfaces A, B and 
C in figure L, are iisted below. The signals are divided 
into categories of' normal and returned signals. 


5,1 Interface A 




5.1.1 Signals sent from APP_DIR to line handlers 


Normal signals 




SJ4PAK 

origin = 
from = 
signal_status = 
signal type = 
MPAK 


creator of this signal 
APP DIR 

signal status ok , 
S MPAK 

MPAK in question 


S_not_sent_MPAK 

origin = 
from = 
signal status = 
signal type 
MPAK 


creator of original MPAK 
APPJDIR 

signal status ok 
S_not-sent_MPAK 
MPAK Tn question 


S returned incorrect MPAK 

origin = 

signal_status = 
signal type = 
MPAK 


creator of original MPAK 
APP DIR 

signal status_ok 

S returned incorrect MPAK 

MPAK in question ~ 


S_MPAK_sent_on_radio 

origin ~ - 
from = 
signal status = 
signal type = 


creator of original MPAK 
APP_DIR 

signal_status_ok 
S_MPAK_sent_on_radio 
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5.1.2 Signals sent from line handlers to APP_DIR 




Normal siqnals 








S 1 i ne_jup 

origin 

signal_status 
signal_type 


= 


line handler in question 
origin 

signal_status ok 
S_line_up 




S_line_down 
origin 
from 

s ignal_status 
signal~type 




line handler in question 
origin 

s i g na l_s t a tus_o k 
S_line~down ~ 




S_MPAK 

origin ■• 
from 

signal status 

signal~type 

MPAK 




line handler in. question 
origin 

signal status ok 
S MPAK" 

MPAK in question 




Returned siqnals 








S_MPAK 

origin 
from 

signal_status 
signal type 
MPAK 




no change in this field 
line handler in question 
signal status not sent 
S MPAK ~ ~ 
MPAK in question 




S_MPAK_sent on radio 
origin ~ 
from 

signal status 
signal~nype 




no change in this field 
line handler in question 
signal status not sent 
S_MPAK_s e n t_o n_r aai o 




S_returned incorrect MPAK. 
origin = 
from = 
signal status = 
signal~type = 
MPAK 


no change in this field 
line handler in question 
signal_status not sent * 
S_returned_incorrect_MPAK 
MPAK in question 


3;U.i.r. 


S_not_sent MPAK 
origin 
from 

signal status 
signal type 
MPAK 




no change in this field 
line handler in question 
signal status not sent 
5_not_sent_MPAK ~ 
MPAK in question 
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5.1.3 Signals from APPJJIR to AUDIO 


All signals listed in 5.1.1. 




5.1.4 Signals from AUDIO 


to APP_DIR 


All signals listed in 5.1.2, 


plus the following: 


S_hook_off 

origin 
from 

signal_status 
signal~type 


ii ii ii n 




AUDIO 
AODIO 

signal status ok 
S_hook_off ~ 


S_hook_on 

origin 
from 

signal status 
signal type 






AODIO 
ADD 10 

signal status ok 
S_hook_on ~ 


5.1.5 Signals from APPJ3IR to RADIO_NET 


Normal siqnals 








S_HPAK 

origin 
from 

signal status 
signal type 
MPAK ~ 


M II II II II 




creator of this signal 
APP_DIR 

signal status ok 
S_MPAK 

MPAK in question 


S_hook on 

origin 
from 

signal status 
signal_type 






AODIO 
APP DIR 

signal_status ok 
S_hook_on ~ 


S_hook_off 

origin 
from 

signal status 
signal type 






AODIO 
APP DIR 

signal_status ok 
S_hook~off 
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S.1.6 Signals from RADIOJ3ET to APP_DIR . 


Normal signals 






S_MPAK 






origin 




RADIOJIET 


from 


= 


origin . 


signal_status 


= 


signal status ok 


signal type 




S MPAK 


MPAK 


'" 


MPAK in question 


Returned siqnals 






S_KPAK 






origin • 




no change in this field 


from 




RADIOJIET 


signal_status 




signal status not sent 


signal*~type 




S_MPAK~ 


MPAK 




MPAK in question 


S_hook_on 






origin 




AUDIO 


from 




RADIOJJET 


signal_status 




signal_status not sent 


signal_type 




S_hook~on 


S_hook off 






origin 




AUDIO 


from 




RADIO NET 


signal status 




signal status hot sent 


signal~type 




S hook off 
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6 REGISTERS IN APP_DIR 

Four registers are kept in APPJ3IR: 

6.1 Register number one: MCOJREG 

The register called MCD_REG has the structure shown in the 
figure below. 



LINE 


MASC1 MASC2 MASC3 ADDIO PRINTER 


MAY / MAY NOT 
INACTIVATE MCO 




LINE OP / 
LINE DOWN 






TEXT 






STATUS 




MSG 
TYPE 


DATA 




HP DATA 






SPEECH 






EMERGENCY 











line 

Contains the line handlers that exist in this 
application. This is static information. 

msg type 

Tells which MPAKs, addressed to MCU_MAN or any MAN in the 
grouplist, will be received by the Tine handler. As an 
example, there is nothing to prevent that MPAK- TEXT is 
received by a number of line handlers. In the speech 
connection case, in this particular application, only 
one line handler can be enabled. Msg type contains static 
information. 

may/may not inactivate MCO 

Tells whether the line handler in question is allowed to 
inactivate MCO with an MPAK DTESERV . INACTIVE . Normally,, 
only one (or very few) of the line handlers should be 
allowed to do this. This is static information. 
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line up/down 

Contains information about each of the connected line 
handlers. This information is dynamic. 



The figure below shows how the MCU_R£G may be used. 



LINE 


MASC1 MASC2 MASC3 AUDIO PRINTER 


MAY / MAY NOT 
INACTIVATE MOT 


MAY NOT NOT NOT NOT 


LINE U 
LINED 


P / 
OWN 


UP UP DOWN UP UP 


MSG 
TYPE 


TEXT ' 


XXX X 


STATUS 


X 


DATA 


X 


HP DATA 


X 


SPEECH 


X 


EMERGENCY 


X 


EXTPAK 


X 



In this case, only MASC1 is allowed to inactivate the MCU. 
All line handlers, except for MASC3 , are connected and 
intact. When APP_DIR receives an MPAK TEXT from MOBITEX 
network, it will be sent to MASC1, MASC2 and PRINTER. Since 
MASC3 does not have status line up, it does not receive any 
MPAKs. Received MPAK STATUS is to be sent to AUDIO. Other 
MPAKs are to be sent to MASC1. 

Observe that APP_DIR does not keep information of if MCU is 
active or inactive. Nor does APP_DIR know if radio NET has 
received an MPAK DIE from the MOBITEX network. It is che 
responsibility of RADIO_NET to keep information about this . 
If RADIO_NET notes which APP_DIR is not allowed to send to 
the MOBITEX necwork, the packets are returned to APP DIR 
with signal status set to signal_status_not_sent . 
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6.2 Register number two: FLEXLIST 

The FLEXLIST register has the structure shown in the figure 
below. 



• The HOB I TEX subscription number of the transferred 
subscriber. Up to seven M&N-numbers are allowed. 

■""The line handler to which the transferable has 
transferred. . 

• Tells login status. 

It can be: UNDER_LOGIN - the login sequence is not 
yet finished 
0K_L0GIN - the login sequence is 
finished and accepted 



6.3 Register number three: GROOFLIST 

The GROUPLIST contains a list of group MAN numbers. Op to 15 
MAN numbers is allowed. 



6.4 Register number four: CONNECTION_REG 

CONNECTION REG keeps information about the status of the 
speech line. It contains the following information: 

CONNECTION_STATUS 



CONNECTION PARTY HERE ■ 



• can be free, busy or 
waiting_for_hook_of f 

MAN number for connection part in 
the MCU 



CONNECTION_OTHER_PARTY - MAN number for the other connection 
~ part 



CONNECTION_CONN ID 



- connection identity for current 
speech line connection 
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7 REQUIREMENTS ON THE NETWORK LAYER IN- MCO 

Requirements on Che network layer in MCO (RADIO_NET) are 
listed below: 

1. Everything applicable to mobile terminal in document 
MOBITEX network layer for terminals, 5/1056 - A 296 
5171. 

2 All MPAKs that the application wants to send via radio 
and network layer to 

- be acknowledged to the application if the transmission 
was successful, 

- be returned to the application if the transmission 
failed. 

3 The signals hook_on and hook^off will be returned to the 
application if the transmission via radio 'fails. 

4 The following MPAKs, received by the MCD via radio, to 
be sent to the application: 

- all MPAKs of class PSOBCOM 

- all MPAKs of class PSOSCOM. 

Note that a transferred subscriber, connected to 
the MCO via an'MASC handler, can be. emergency 
receiver. 

- following MPAKs, belonging to the class CSDBSOM: 



+ ADDCONREQ 
+ SOSCONREQ 
+ EXTCONREQ 
+ CONORD 
+ DISCON 

- following MPAKs, belonging to the class DTESERV: 
+ LOGINREQ * ** 

+ LOGINREF ** 
+ LOGOOTORD ** 



+ FLEXLIST ** 

+ TIME 

+ GROOPLIST ** 

+ SOSRX * *** 

+ VICESOSRX * *** 

* These MPAKs can only have MPAK states that are not OK. 
** These MPAKs concern flexlist and grouplist. They are 

handled by the network layer and sent to the 

application. The reason for this is that the application 

has copies of flexlist and grouplist. 
*** Only if a terminal, connected to the MCD, has an 

emergency receiver transferred to it. 



A-J32 515M 
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8 REQUIREMENTS OH A PIXED TERMINAL 




The recruirements for a fixed terminal which is able to 
connect to the MOBITEX network as well as the MCU are as 
follows . 




Link layer 






Frames in the masc protocol for implemented: 




All control frames 


ACK, RACK, NACK, SENS, SACK 




Following information frames: 

B, M, E, R, F_P, F_Q, N 




Network layer- 






The MOBITEX network considers a fixed terminal, connected 
via an MCO, as a mobile terminal. This has the following 
consequencies as to which MPAKs may be sent and received by 
the terminal:. 




class PSOBCOMs 

The terminal is allowed to send and receive all MPAKs 
in this class. . 




class- PSOSCOM: 

An emergency sender can be a mobile subscriber or a 
transferable subscriber which is transferred to a 
mobile subscriber. A receiver can be a fixed terminal 
subscriber or a transferable subscriber. 
All emergency senders can send SOS and receive SOSACK. 
Furthermore, all mobile terminals are be able to 
receive SOS and SOSACK addressed to All terminals 
group MAN. 




class CSUBCOM: 

If the fixed terminal has one line for speech line 
connection, the following MPAKs can be received and 




CONREQ 






SOSCONREQ 
ADD CONREQ 






EXTCONREQ 

CONREA 

DISCON 






Connection to group will be made by the MCU by 
converting CONORD to CONREQ. 
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Class DTESERV: 

Following MPAKs may be sent: 
LOGINREQ . 
LOGOUT 
ACTIVE 
INACTIVE 
VICESOSRX 
SOSRX * 
FLEXLIST * 

* Only if the sender is a transferable subscriber. 



Following MPAKs shall be received: 
LOGINREQ 
LOGINGRA 
LOGI-NREF 
LOGODTORD 
VICESOSRX 
— SOSRX - — — 
GROCIPLIST 
. FLEXREQ 
TIME 



When the network layer receives masc frame N 'from the 
masc interface, it acts in the same manner as if the 
MPAK never leaved the fixed terminal. 
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9 PSEODO CODE FOR APPJDIR 


! 


In this pseudo code all procedures start with "P_", and all 
functions with "F_'' . 




REPEAT 

Wait for input . 
CASE input signal_type OF 
S MPAK sent on radio 
"IF from =~RADIO_NET THEN 

send this signal to origin 
ELSE 


i 


forget this signal 
END IF 
S_hook_on 

P hook on 
S hook off •• 
P_hook_off 
S line up 

~P_line_up 

S_line^down 
"~P line down 
S MPAK 

~P_MPAK 
conord timer 

CONNECTION_STATUS = free 
otherwise 

forget this signal 
END CASE input signal OF 
UNTIL forever 




P hook on 

IF ( from = AUDIO ) AND 


( CONNECTION_STATUS <> free ) 




send this signal to RADIO NET 

send signal S MPAK with MPAK = DISCON to 

CONNECTION LINE 

(MPAK. sender = CONNECTION OTHER PARTY 
MPAK. addressee = CONNECT ION_PARTY_HERE 
MPAK. type dependent. line number =~0 
MPAK . type - dependent . CONN ID=CONNECTION CONN ID) 

CONNECTION STATUS = free 




ELSE 

forget this signal 
END IF (from = ADDIO) AND ( CONNECT ION_STATUS ofree)... 
END P_hook_on 
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PJiook off 

IP from = AUDIO THEN 

IF CONNECTION_STATUS = waiting_f or_hook_of f THEN 
CONNECTION STATUS = busy 
send this signal to RADIO_NET 
reset conord_timer 
ELSE 

forget this signal 
END IF CONNECTION_STATUS = waiting for hook_off... 
ELSE 

IF (from=RADIO_NET) AND ( signal_status = 

signal_status_not_sent) THEN 

forget this signal 

send signal S_MPAK with MPAK = DISCON to 
CONNECTION LINE 

( MP AK. sencTer = CONNECTION_OTHER_PARTY 
MPAK. addressee = CONNECT I ON_P ART Y_HERE 
MPAK.type dependent. line number = 0 
MPAK.type2deoendent.CONN_ID = CONNECT I ON_CONN_ID ) 
CONNECT ION_STATUS = free 

- ELSE 

forget this signal 
END IF (from = HADIO_NET) AND (signal_status = . . . ) 
END IF from - AUDIO..." 
END P_hook_off 



P_line_down 

mark origin in MCU_REG as line_down 

FOR all MAN in our flexlist pointing at origin DO 

send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK. sender = MAN in question from flexlist 
MPAK. addressee = the MOB I TEX network 
MPAK.type_dependent part = MCU_MAN ) 
remove MAN in question from our flexlist 
END FOR all MAN in our flexlist pointing... 
END P_line_down 



P line up 

send signal S MPAK with MPAK = grouplist to origin 
( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU_MAN 
MPAK.type_dependent_part - our grouplist ) 
send signal S_MPAK with MPAK « flexreq to origin 
( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU MAN ) 
mark origin in MCU_REG as line_up 
END P_line_up 
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P_HPAK 

IF signal status = signal_status ok THEN 
IF frora~= RADIO_NET THEN 
P_MPAK_f rom_radio 

P_MPAK_from_other 
END IF from = HADIO_NET ... 
ELSE 

IF origin = from THEN 

forget this signal (can't send this signal in any 
direction } 

ELSE 

IF origin = RADIO_NET THEN 

forget this signal (Never send back MPAK to 
network) 

ELSE 

IF MPAK.unknown_f = 0 THEN 
CASE MPAK.packet_ciass OF 
PSUBCOM,PSOSCOM 

signal status = signal_status_ok 
signal~type = S_not_sent_MPAK 
send this signal to origin 
CSDBCOH 

CASE MPAK. pack et_type OF 
CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ 
signal_status = signal_status_ok 
signal_type = S_not_sent MPAK - 
send this signal to origin 
CONNECTION_STATOS = free 
otherwise ~ 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK. packet type OF 
VICESOSRX,SOSRX 

signal_status = signal_status_ok 
signal_type = S_not_sent_MPAK~ 
send this signal to origin 
LOGINREQ 

remove MPAK.type_dependent_part from our 
flexlist 

signal_status = signal status_ok 
signal~type = S_not_sent MPAK 
send this signal to origin 
otherwise 

forget this signal 
END- CASE MPAK.packet_type. . . 
END CASE MPAK. class. . . 
ELSE 

forget this signal 
END IF MPAK.unknown_f . 
END IF origin. . . 
END IF origin... 
END IF signal_status. . . 



Exhibit 2, p. 826 



Cantel Mobitex~ 



1/1056 A 296 5175 Ue 

3T= .•». r=T tt-tt 

1990-02-23 B | MTS19B.1 



P_MPAK_from_otner 

mark origin in MCU REG as line up 
CASE MPAK. packet class OP 
PSUBCOM.PSOSCOM ~ 

IP MPAK . unknown_f = 1 THEN 

IF (F_get_receiver_MAN in our grouplist ) OR- 
[F_get_receiver_MAN = MCU_MAN ) THEN 

forget this signal 
ELSE 

IP F_get_receiver_MAN in our flexlist THEN 
remove F_get receiver_MAN from our flexlist 
send signal S_MPAK with MPAK = LOGOUT to RADIO NET 
( MPAK. sender = F_get receiver_MAN "" 
MPAK. addressee = the MOB I TEX network 
MPAK.type_dependent_oarf = MCU MAN ) . 
END IF F_get_receiver_MAN in our" flexlist ~ 
send this signal to RADIO NET 
END IF tF_get_receiver_MAN In our grouplist... 
ELSE ( IF MPAK. unknown f = 1 ...) 

IF (MPAK. state <> OK~) OR { MPAK.digital_f =1 ) THEN 

signal_type = S_returned_incorrect_MPAK 

send this signal to origin 
ELSE 

IF (F_get_transmitting_MAN = MCD_MAN ) or 
(P_get_transmitting_man in our flexlist with status 
ok login ) THEN 

send this signal to RADIO NET 
ELSE 

send signal S_MPAK with MPAK = LOGOOTORD to origin 
(MPAK. sender = the MOBITEX network 
MPAK . addressee = MCU_MAN 

MPAK.type_dependentjpart= F get transmittina MAN) 
signal_type = S not_sent_MPAK ~ 
signal~status =~signal_status_ok 
send this signal to origin 
END IP (F get transmitting MAN = MCU MAN... 
END IF MPAK. state... 
END IF MPAK. unknown f... 
CSDBCOM 

CASE MPAK. packet type OF 
CONREQ , ADDCONREQTSOSCONREQ , EXTCONREQ 
IF ( MPAK . unknown_f - 0 ) and 
( MPAK.mailbox_f = 0 ) and 
( MPAK.sendlist_f = 0 ) and 
( mpak. state = OK ) THEN 
IF (F_get transmitting MAN = MCU_MAN ) or 
(P_get_transmitting_MAN is in our flexlist with 
status ok_login ) 
THEN 

IF CONNECTION STATUS = free THEN 
CONNECT ION_3Ti ne = origin 
CONNECTION_status = busy 
send this signal to RADIO_NET 
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ELSE 

signal_type = S_not_sent_MPAK 
signal_status = signal scatus_ok 
send this signal to origin 
END IF CONNECTION STATUS = free... 
ELSE 

send signal S_MPAK with MPAK = LOGOUTORD 
origin 

( MPAK. sender = the MOB I TEX network 
MPAK. addressee = MCU_MAN 
MPAK.type_deDendent_part = 
F_get transmitting_MAN ) 
signal_type * S_not_sent'_MPAK 
signal_status = signal status_ok 
send this sianal to origin 
END IF (F_get_transmitting MAN = MCU MAN... 
ELSE 

signal_type = S_returned_incorrect_MPAK 
send this signal to origin 
END IF ( MPAK.unknown_f =0... 



IF ( CONNECTION STATUS '= waiting for hook_off) and 
( origin = CONNECTION_line ) THEN 

forget this signal ~ 
. send signal S_hook_off to RADIO_NET 

CONNECT ION_STATUS = busy 

reset conord_timer 
ELSE 

forget this signal 
DISCON 

IF ( CONNECTION_STATUS <> free) and 
( origin = CONNECTION. line ) THEN 

forget this signal 

send signal hook on to RADIO NET 

CONNECTION_STATUS = free 
ELSE 

forget this signal 
otherwise 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK.oacket type OF 

LOGINREQ , LOGOUT , ACTIVE , INACTIVE , VICESOSRX , SOSRX , FLEXLIST 
IF (MPAK. state = ok ) AND 
( MPAK.digital_f = 0 ) AND 
( MPAK,raailfaox_f = 0 ) AND 
( MPAK.sendlist_f = 0 ) AND 
( MPAK.unknown_f = 0 } AND 
( MPAK.extern_f - 0 ) AND 
• ( MPAK. addressee = HOB I TEX network ) THEN 
CASE MPAK.oacket_type OF 
LOGINREQ , ACTIVE , INACTIVE , FLEXLIST 
IF MPAK. sender = MCU MAN THEN 
CASE MPAK.packet_type OF 
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LOGINREQ 

IF MPAK.typejdependentjpart in our flexlist 
with status = ok_login THEN 

send signal S_MPAK with MPAK LOGINGRA to 

origin 

( MP AK. sender = the MOBITEX network 
mpak. addressee = mcu_man 
MPAK.type_dependent_part = 
=<old>MPAK.type_dependent_part ) 
forget this signal 
ELSE 

IP more space exists in our flexlist THEN 
mark MPAK. type dependent_oart in our 
flexlist 

with scatus=under_login and line = 
origin 

send this signal to RADIO_NET 
• ELSE 

signal_type = S_not_sent_MPAK 
signal~status =~signal_status_ok 
— -.send this signal to origin ~ 
END IF more space in our flexlist... 
END IF MPAK.type_dependent_part in our... 
ACTIVE , INACTIVE 

IF origin may inactivate THEN 
P_line_down 

send this signal to HADIO_NET 
ELSE 

P_line_down 

forget~this signal 
END IF origin may activate/inactivate... 
FLEXLIST 

FOR all MAN in MPAK . FLEXLIST not in our 
flexlist 

with status ok_login DO 

send signal S_MPAK with MPAK = logoutord 
to origin 

( MPAK. sender - the MOBITEX network 
MPAK.addressee = MCU_MAN 
MPAK.type_dependent_part = MAN in 

question ) 

END FOR all MAN in MPAK. FLEXLIST not in our... 
forget this signal 
END CASE MPAK.packet_type 
ELSE ( IF MPAK. sender = MCU MAN) 

signal_type = S_returned^_incorrect_MPAK 
send this signal to origin 
END IF MPAK. sender = MCU_MAN. . . 
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VICESOSRX,SOSRX 

IF MPAK. sender in our fiexlist. with status 
ok_login THEN 

send this signal to RADIO_NET 
ELSE 

signal_type = S_not_sent_MPAK 
signal_status = signal_status_ok 
send this signal to origin from 
END IF MPAK. sender in our fiexlist with status. 
LOGOUT 

IF MPAK. sender in our fiexlist with any status 
THEN 

delete MPAK. sender from our fiexlist 
MPAK.type_dependent_part = MCU_MAN 
send this signal to~RADIO NET " 
ELSE 

forget this signal 
END IF MPAK. sender in our fiexlist ... 
END CASE MPAK. packet type... 
ELSE 

signal.- type .j? S_returned_incorrect_MPAK 
send this signal to origin 
END IF (MPAK. state = ok... 
otherwise 

signal_type = S_returned_ i _incorrect_MPAK 
send this signal to origin 
END CASE MPAK.packet_type. . . 
END CASE MPAK. Class. . . 

2ND P MPAK from other 



P MPAK from radio 
CASE MPAK. class OF 
PSDBCOM,PSOSCOM 

IF F get_receiver MAN in our fiexlist THEN 

send this signal to line in question 
ELSE 

IF ( F get_receiver_MAN = MCU_MAN ) OR 
( F_get_receiver_MAN in our grouplist ) THEN 
CASE MPAK. class OF 
PSOBCOM 

CASE MPAK.packet_type OF 
TEXT 

P_copy_and_send_signal{ text ) 
STATUS 

P_copy_and_send_signal( status ) 
HPDATA 

P_copy_and_send signal ( hpdata ) 
DATA 

P_copy_and_send_signal( data ) . 
EXTPAK 

P_copy_and_send_signal (EXTPAK) 
otherwise ~" 

forget this signal 
END CASE MPAK. packet type... 
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IF ( MPAK.packet_type = SOS or SOS INFO ) 

AND ( MPAk. addressee = all terminal group MAN ) 

THEN 

IF MPAK. sender in out flexlist THEN 

send this signal to line in question 
ELSE 

P_copy_and_send_signal( emergency ) 
END IF MPAK. sender in our flexlist... 
ELSE 

P_copy and_jsend_signal{ emergency ) 
END IF (~MPAK.packet_type .=. SOS or SOSINFO.. 
END CASE MPAK. class... 
ELSE 

( This case can not appear; the network layer shall 

take care of unknown MPAKs from the network) 
MPAK. unknown f = 1 
send t-his signal to RADIO NET 
END IF ( F_get_receiver_MAN~= MCD_MAN... 
END IF F_get_receiver MAN in our flexlist... 
CSOBCOM ....... _. 

CASE MPAK.packet_type OF 

CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ 
IF MPAK. State <> ok THEN 

P_discon 
ELSE 

IF F_get_receiver_MAN in our flexlist THEN 
CONNECT I ON_S T ATOS = waiting_f Dr_hook_of f 
CONNECTION^ INE = line in question from flexlist 
CONNECTION_PARTY_HERE = MPAK. addressee 
CONNECTION_OTHER_PARTY = MPAK. sender 
CONNECTION_CONN_ID =MPAK. type_dependent . conn_id 
send this signal to line in question 

IF F_get_receiver_MAN = MCO_MAN THEN 

CONNECTION_STATUS = waiting_for_hook_of f • 
CONNECTION_PARTY_HERE = MPAK. addressee 
CONNECTION OTHERJPARTY = MPAK. sender 
CONNECTIONj:QNN_ID =MPAK. type_dependent . conn_id 
send this signal to first line in MCD_REG with 
(line_status = up) AND (msg_type = speech) 
IF no such line THEN 
forget this signal 

CONNECT ION_STATDS = waiting_for_hook_of f 
send signal S_hook on to HADIO_NET ~ 
ELSE 

CONNECT I 0N_L INE = line in question from 
MCU_REG 
END 
ELSE 

forget this signal 
send signal S_hook_on to RADIO_NET 
END IF ( F get receiver_MAN = MCU_MAN... 
END IF F GET"receiver MAN in our flexlist... 
END IF MPAK. state <> ok 
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IP CONNECTION STATUS = free THEN . 

IF F get receiver MAN in our grouplist THEN 
MPAK . packet_type = CONREQ 
CONNECT ION_STATUS = waiting_£or_hoak_o££ 
CONNECT ION_PARTy_HERE = HPAK. addressee 
CONNECTION_OTHER_PAR.TY = MPAK. sender 
CONNECTION CONN_ID= MPAK.type_dependent.conn_id 
send this signal to first line in MCU_REG with 
( line_status = up ) AND ( msg_type = speech ) 
IF no such line THEN 
forget this signal 
CONNECTION STATUS = free ' 
send signal S hook on to RADIO_NET 
ELSE 

CONNECTION^ INE = line in question from HCO_REG 

set timer: conord_timer 
END 
ELSE 

forget this signal 
send signaT S_hook_6h to HADTOJNET 
END IF F_get_receiver HAN in our grouplist... 
ELSE 

forget this signal 
END IF CONNECTION_STATDS = free... 
DISCON 

P_discon 
otherwise 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK. pack et_type OF 
LOGINREQ , LOGINHEF , LOGOUTOHD 

IF MPAK.type_dependent in our flexlist THEN 
send this signal to line IN QUESTION 
remove MAN in question from our flexlist 
ELSE 

forget this signal 
END IF MPAK.type_dependent in our flexlist THEN 
LOGINGRA 

IF MPAK. type dependent in our flexlist THEN 
mark in our flexlist status = ok_login 
send this signal to line in question 

send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK, sender = MCU_MAN 
MPAK. addressee = MOB I TEX network 
MPAK. type dependent_part = MAN in question 
■END IF MPAK.type_dependent in our flexlist 
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FOR all MAN in this signal who are not in our fiexlist 
send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK . sender = MCU MAN 
MPAK. addressee ■ ""MOBITEX network 
MPAK. type dependent_part = MAN in question) 

END 

FOR all MAN in our fiexlist who are not in this signal 
send signal S_MPAK with MPAK = logoutord to line in 
question 

( MPAK. sender = MOBITEX network 
MPAK. addressee = MCO_MAN 

MPAK.type_dependent_part = MAN in question ) 
remove MAN in question from our fiexlist 
END 
TIME 

send a copy of this signal to all lines 
GROOPLIST . 

store grouplist from this signal in our register 
send a copy of this signal to all lines 

SOSRX,-VICESOSRX ■•- 

IF F_get_receiver_MAN in our fiexlist THEN 

send this signal to line in question 
ELSE forget this signal 
END CASE MPAK. packet type OF... 
END CASE MPAK. class. . 
MD P MPAK from radio 



P_copy_and_send signal ( type } 

send a copy to all lines in MCD_REG with 

( line_status = up ) and [ msg_type = type ) 

END P_copy_and_send_signal 



P_discan 

IF CONNECTION STATUS <> free 

send this sTgnal to CONNECTION^ INE 
. CONNECTION_STATUS = free 
ELSE 

forget this signal 
END 

END P_discon 



Exhibits p. 833 



Cantel Mobitex- 



1/1056 - A 296 5175 Ue 



1990-02-23 B 



F_get receiver_MAN 
CASE MPAK. state OF 
ok,£rora_mail 

F _9 et _ receiv er_MAN = MPAK. sender 
otherwise 

F_get receiver MAN = MPAK. addressee 
END CASE 
END F_get_receiver_MAN 



F_get_transmitting_MAN 

IF MPAK.unknown_f = 0 THEN 



= F_get_receiver_MAN 
END F_get_transoitting_MAN 
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10 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

. Rl-09, 3 
Rl-16, 3 



Below are the reference designations listed. 

Reference Section 

Rl-01 .- Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

111-11 Interface requirements-, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

&L-n Physical layer, mobile terminals 

Rl-18 Radio, equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

R!-20 Other requirements, mobile terminals 
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HOBITEX 

General requirements, mobile term. • 



The general requirements for MOBITEX mobile terminals are 
described in this document. These include environmental 
requirements, power supply requirements, the minimum 
requirements for controls and indicators and special 
requirements in connection with the type approval testing. 
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1 ENVIRONMENTAL REQUIREMENTS 

The equipment must be operational also under the extreme 
temperature' conditions. No error functions which can 
interfere with the operation of the MOBITEX network must 
occur under any environmental condition. 



1 . 1 Temperature 

The normal operational temperature" range: 

+15 to +35 degrees C. 
The extreme operational temperature range: 

-25 to +55 degrees C. 

The equipment should be such that it is not damaged by 
storage in the temperature range of: 

-40 to +70 degrees C. 

1.2 Relative humidity 

Mobil terminal should be able to withstand 20-75% RE. 

1.3 Vibrations 

The equipment should be able to withstand a vibration test 
in accordance with IEC publication 68-2-6: 

10 - 55 Hz +/- 0,15 mm movement. 

55 - 150 Hz 20 m/s square acceleration. 

Sweep rate: 1 octave per. minute 

Duration: 2 hours in each of the three directions. 

The equipment should not be in operation during the test 
but should comply with the requirements in the MOBITEX 
terminal specification after the test. 
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2 POWER SUPPLY 

2.1 nominal voltage 

The nominal voltage is optional and should be stated by 
the manufacturer. 



2.2 Voltage limits 

Equipment designed for working from lead acid accumulators 
in a vehicle should comply with the specifications when 
the voltage varies from 0.9 to 1.3 times the nominal 
voltage. 

Equipment designed for operating on an alternating voltage 
should comply with the specifications when the voltage 
varies by +10%. 

If these limiting values are exceeded, error functions 
which can interfere with the operation -of the network 
should not occur. 



3 HARKING 

The equipment should be clearly marked with the 
manufacturer, type designation, serial number, approving 
text {"Approved by ... ") and registration number of the 
type approval. The marking should be engraved on metal and 
permanently fixed to the equipment. 

The mobile terminal's subscription number should be 
clearly visible or accessible. 



3.1 Electronic serial number check 

The serial number should.be stored together with the 
terminal subscription HAN and permanently in such a way 
that they are impossible to change by software or by 
unauthorised persons, preferably in enchrypted form. 

The serial number of the equipment should be checked in 
the terminal against the serial number stored together 
with the MAN at power on. If the numbers are not equal, it 
should be impossible to use the equipment. 

In addition, the serial number (ESN) is sent to the 
network at "activation", to be checked with the serial 
number stored in the network (see reference Rl-09). 



■353 
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There are no requirements for type approval of controls. 
There are certain recommendations however. 

If number keys for number keying are used, they should 
comply with one of the following minimum configurations. 

12345*AB 
67890#CD 

12 1 2 3 A 

3 4 4 5 6 B 

5 6 7 8 9 C 

7 8- * 0 # D 

9 0 
* # 

- A B. 

C D 

The following recommendations apply for the A, B, C and D 
keys. The D key should have the data send function. If 
there is a speech facility, key C is used for "speech 
request". The key should be marked with T. Keys A-and B 
can be used for status or another function and marked 
according to use. 

International standards should be followed if a completely 
alphanumeric keyboard is used. The number keys on the 
keyboard can then be used for number keying as well. 



5 INDICATORS 

An indicator with yellow or amber colour should indicate 
when the power is switched on. 

An indicator with green colour should indicate with a 
steady light when the mobile terminal is in contact with 
the HOBITEX network and with a twinkling light when it is 
not (base search mode). 
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6 TYPE APPROVAL TESTING 

Except the equipment described in the chapters below, 
requirements may be specified by the network operator 
(please refer to reference Hl-06) for equipment such a: 

- Portable antennas 

- Cabling and terminations 

- Terminal display 



6.1 Equipment to be type approved 

The type approval test applies to the radio equipment and 
to the physical, link and network layers of the mobile 
equipment-according to these specifications. Application 
layer functions are only tested if under special 
requirements when installed. 

The type approval only applies to the software tested. If 
a change is made in any software scored in the same 
storage unit as the software handling the tested 
functions, a new type test must be made. The testing 
authority should determine at its discretion and based on 
documentation of the modifications, wether new 
measurements are necessary for a new approval. 

Optional terminal equipment to be connected to the radio 
control unit is not type tested. 



6.2 Normal test conditions 

The mobile terminal should be tested in the normal 
environment stated above. The specified data should be 
complied with for all combinations. 

Terminals designed for operating on lead acid accumlators 
in vehicles should be tested at 1.0 times the nominal 
voltage. 

The terminal should be ready for operation within 1 minute 
of switching on the power. 



6.3 Extreme test conditions 

Additional environmental requirements can be made' in 
reference Rl-06 (Network operator information). 
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The mobile unit should be tested at the lower and upper 
limits in the temperature and voltage ranges stated above. 

Before testing is carried out, the equipment should have 
achieved thermal equilibrium in the test chamber. The 
power supply should be switched off during this period. 
Measurements should be carried out in such a sequence and 
with relative humidity controlled so that excessive 
condensation does not occur. 

Testing at the upper temperature limit should begin with 
the sender in the send position for 1 minute and receiving 
for 4 minutes after which measurement's are carried out. 

Testing at the lower temperature limit should 
1 minute after switching" on the power supply. 
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6.4 Teat connections, interfaces and controls 

For the type approval test, the mobile terminal should be 
equipped with test ' connections and manual controls to 
permit the measurements that are necessary to verify that 
the specification requirements are complied with. This 
applies particularly to the requirements stated in 
'reference Rl-18 {"Radio equipment, mobile terminals" and 
"Measurement methods"). These connections and controls can 
be implemented by external test adaptors during the test. 

For the type approval test, the equipment should also be 
equipped with the "Machine interface (MASC)" as described 
in reference Rl-19 ("Other interfaces, mobile terminal", 
minimum basic and type test functions). This interface can 
be implemented by an external test adaptor during the 
test. 

Equipment intended to be used as partially active in 
"MOBXTEX should be possible to operate as a normal mobile 
terminal during the tests, i.e. continuously listening to 
MOBITEX. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on- Please note that a section could be 
referred to several times on the same page. 

Rl-06, 6 
Rl-09, 4 

ri-18, a 

Rl-19, 8 



Below are the reference designations listed. 
Reference . Section 

Rl-01 Arrangement of the documents 

;; ,Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

R1-0S Application layer 

Rl-09 Network layer 

Rl-ll Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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